Re: Userdata finalization order

[<jgiors@...>]

> ------------------------------
> 
> Message: 3
> Date: Tue, 19 Oct 2010 17:06:08 +0200
> From: Francesco Abbate <francesco.bbt@gmail.com>
> Subject: Re: Userdata finalization order
> To: Lua mailing list <lua-l@lists.lua.org>
> Message-ID:
> 	<AANLkTimGqg11tvndESaBwzRESOqm9qotezKdRx_RHWfA@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 2010/10/19  <jgiors@threeeyessoftware.com>:
> > By your description, it sounds like an "owner" pattern -- plot A owns
> > line B, and on the C++ side, B is deleted when A destructs, i.e. B would
> > not be deleted independently from A if you were writing the app in C++.
> >
> > So, couldn't this problem be avoided by *not* having a finalizer for
> > line B?
> >
> > i.e. the only way line B would be C++ destructed is when plot A's
> > destructor is called and it deletes all contained elements (one of which
> > is line B).
> >
> > This would work on final cleanup and also if plot A were dereferenced
> > prior to final cleanup. You would still need to ensure no Lua code
> > dereferences line B independent of plot A.
> 
> Well, this is quite not true because the object B can exists also
> indipendently from object A. For example you can write in GSL shell
> the following code:
> 
> ln = fxline(sin, 0, 2*pi) -- create a "line" object
> p1 = plot('Test plot #1') -- create a "plot"
> p1:addline(ln)
> p2 = plot('Test plot #1')
> p2:addline(ln)
> 
> As you can see the object "ln" can exists indipendently from any plot
> but it can also be attached to one or many plot (this is the zero,
> one, infinity principle, I guess :-) )
> 
> So neither "p1" or "p2" owns the object line. The object line exists on its own.
> 
> Note that this pattern is perferctly normal for Lua and if all the
> objects were native Lua objects there would be absolutely no problem.
> The GC knows about the existing objects and know that p1 refers to
> "ln" so that it will never deallocate "ln" as far as either p1 or p2
> are alive.
> 
> The troubles came when ln, p1, p2 and C++ objects since, as I'm trying
> to explain, Lua does not have any satisfying mechanism to ensure
> proper management of the reference among C++ objects. The only model
> that works is to create a reference counted objects, then create the
> userdata which is just as a boxed C++ pointer and define the Lua
> finalizer function so that it just "unref" the object. In this way the
> object will be freed only when nobody make reference to it and
> everyone will be happy.
> 
> --
> Francesco

I thought the original problem was that, upon finalization, the plot
would attempt to access an element, but the element could have already
been finalized. Why does the plot access elements on finalization? Is
that in order to delete the elements?

If I'm misunderstanding, then the rest is a moot point, but anyway:

If the access is in order to delete elements, that is incorrect (even if
the app were entirely C++), e.g. an element could belong to two plots
and be deleted twice.

Would the following work? Elements have a finalizer (just like before),
but the finalizer for the plot does *not* attempt to delete referenced
elements (nor attempt to do anything else with referenced elements).

John Giors
Independent Programmer
Three Eyes Software
jgiors@ThreeEyesSoftware.com
http://ThreeEyesSoftware.com