Re: w5 GC bug regression? [Re: lua51w4-rvm segmentation fault]

["Adam D. Moss" <adam@...>]

Roberto Ierusalimschy wrote:
> > but __gc runs triggered by lua_close() will be able to reach dead
> > objects (and not necessarily know it) -- ouch.
>
> That is not correct. __gc runs triggered by lua_close() are able to
> reach finalized objects, but not dead ones. lua_close only starts
> killing objects after all __gc methods were called. (At least this
> is what should happen. There may be a bug somewhere...)

Okay, that's a subtle but important piece of information.  It means that
a __gc'd object's memory won't have been freed at this point (as the
lua_state takes ownership of all lua_newuserdata()'d memory), which
is very good and makes me much happier.

However, it does still mean that an object will remain accessible
after its finalization method returns, without other users
necessarily being able to tell the difference between an object
which is post-finalization or not, which given that finalization will
often put an object in an unusable state (closing a file handle,
destroying an X window ID, etc) is really not ideal.

Now this doesn't seem such a severe problem, but it DOES imply that
the __gc metamethod has to have some userdata-specific way of flagging
a userdata as unusable once it is finalized, so that any post-
finalization method-call on this userdata will be able to check this
flag[1] and return harmlessly.

If no-one digs the idea of post-finalized objects safely evaluating to
nil, or non-cycles being collected from leaf to root, then I do think
the post-finalization-accessibility issue deserves a few lines in the
Lua manual because it's quite subtle and unobvious (I don't mind writing
those few lines).

Regards,
--Adam
[1] I think this could be very simply aided by allocating an
extra standard flag word in lua_newuserdata() and adding a flag-
checking lua_userdataislive() utility macro, if this is a desirable
approach (I'm not so keen on it myself).
--
Adam D. Moss   -   adam@gimp.org