RE: Feature suggestion: "Up values for userdata"

[virgil@... (Virgil Smith)]

Um, I'm not sure why you think cycles won't be garbage collected (the whole
point of mark and sweep garbage collection, is that "unreachable" cycles
will be garbage collected).  Now of course this brings up order of
finalization issues, but Lua finalizes objects in reverse order of creation,
so if you need your "associated values" to be present when the GC handler
for your userdata runs, then in your user data creation process create the
associated values before the userdata itself (and document the heck out of
why).

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Mark Hamburg
Sent: Wednesday, September 03, 2003 1:49 PM
To: Lua list
Subject: Re: Feature suggestion: "Up values for userdata"


The reference solution runs into the same problem as weak tables with
creating cycles that won't be garbage collected.

Mark

on 9/3/03 10:47 AM, Virgil Smith at virgil@nomadics.com wrote:

> Sounds like a good use for references.
> Just put the "attached" values in a table in the registry and keep a
> reference in the userdata.
> In the userdata's GC method, unlock the reference.
>
> The "tricky" bit is to make GC work correctly.  As a "poor" solution you
> could write a "lua_freeuserdatavalues(L, index_of_userdata)" and require
> that userdata GC methods call this function.  As a "good" solution you
could
> write a new version of setmetatable that checked the GC method and if it
was
> not already "fixed" then "fix" it to reference a function that retrieves
the
> original GC function from somewhere (probably from the metatable or the
> "associated values" table), calls that function, and then "frees" the
> associated data values.
>
> <Definitions of "poor" and "good" are purely my opinion, you have to
decide
> if "mucking" with the metatables is better than relying on the userdata GC
> methods manually calling something.>