Re: Userdata finalization order

[Francesco Abbate <francesco.bbt@...>]

2010/10/20 Wesley Smith <wesley.hoke@gmail.com>:
> -- add the line a to plot b as a dashed line
> b:addline(a, 'red', {{'dash', 7,3,3,3}})
> Does b, being a plot, keep a reference to the line, a, somewhere internally in it's C++ structures?  If so, a should either be added to b's environment table or reference counted.  If you're adding it to the env table, b should not try to use a when __gc is called or when it is freed IMHO

Well, here we came to the point.

I've at some point used environment table but I've rejected this
option because this solution was not able to ensure the correct
finalisation order of plot and lines. I need correct finalisation
order because during plot finalisation I need to query the element to
know if they are Lua allocated or C++ allocated.

> Now that I see this code, it occurs to me that the design problem
> you're facing is not unlike that of OpenGL with both client and server
> code.  If I were doing this in OpenGL, line would be a buffer of
> geometry data stored client side and dispatched to the server, which
> copies the data internally for its own usage.  Of course with OpenGL,
> you can also map memory and create objects that store such memory, but
> these all clearly live on the server.  Perhaps this design strategy
> could serve as inspiration for your project.

For me this would mean that either:
- the plot make a full copy of the line (graphical element) => this is
suboptimal because
  it does waste memory and CPU cycles
- we define a specific plot at the beginning as being the owner of
each created line so that
  the plot in the only owner of the resources => it can work and
simplify the design but restrict the freedom of the user and limit its
possibities

> In the OpenGL bindings to textures, FBOs, vertex buffers, etc. that
> I've written, large blocks of image and geometry data are passed
> around with a generalized memory buffer that is reference counted.
> All other objects use the memory buffers internally to pipe data
> around but are themselves not reference counted.  I wonder if such a
> design might help you here.  For example:
>
>
> a = fxline(sin, 0, 2*pi) -- create a line
> b = plot('Test plot')
> -- add the line a to plot b as a dashed line
> b:addline(a:data(), 'red', {{'dash', 7,3,3,3}}) -- use the data method
> to get the geometry data
> b:show()

Well, in this case it would be simple to have reference counted object
and just pass them around without the "data" method.

I believe that now we have really covered all the relevant points
about this subject. What I retain is that:
- Lua is not able to ensure a particular finalisation order
  => the objects are finalized in reverse creation order. During
finalisation an object should not try to access other objects to which
it refers

This have the implication that I either switch back to reference count
model or I keep the current model by using either weak tables or
environment tables but in this case I have to make sure that each
object does not access to other objects during its finalization.

Thank you very much to all the people that participated to the discussion.

Best regards,
Francesco



-- 
Francesco