Re: Userdata finalization order

[James Rhodes <jrhodes@...>]

On Tue, Oct 19, 2010 at 10:50 AM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> > i can't think of an example where:
> >
> > - A can be created before B
> > - but A depends on B  (how did it exist before B, then?)
> > - you have to destroy A before B
> >
>
> objA = ClassA();
> objB = ClassB();
> objA:Bind(objB);
> -- Now A depends on B.
>
> Regards, James.

A refers to B, but does not "depend on" it. Otherwise, objA would be
in an inconsistent state before the line "objA:Bind(objB)".

It does rely on it because the Bind function takes the address of the userdata stored that was passed to it and stores it within native code.  This address as I understand it becomes invalid once B is cleaned up by the garbage collector, and if that address is accessed by A in it's finalization, then native code will generate an access violation.

It's also not an issue if Bind is never called and A gets cleaned up, because you would have the stored pointer addressing NULL, so you can safely compare that value in finalization (or any other access areas).  However, once that pointer is assigned a memory address, if Lua cleans up that memory address, there's no way to inform A that the pointer is no longer invalid (except for reference counting which is what we're trying to avoid).

Regards, James