Re: Why is "gc" tag method restricted to userdata?

["Philip Yi" <philipyi@...>]

--- In lua-l@egroups.com, Reuben Thomas <Reuben.Thomas@c...> wrote:
> 
> I wonder whether another solution is effectively to manage the GC 
yourself
> in C++: every time you get a call to your GC fallback for a userdata
> object, check whether it points to anything else that might need to 
be
> garbage collected, and if so, queue the current object, rather than
> immediately deleting it.
> 
> The only difference between this and the approach you'd take if you 
were
> able to write fallbacks for table GC is that you have to manage 
state
> across a number of calls, rather than doing it all in one lump (and
> there's still the same problem potentially in the latter case: what
> happens if a C++ userdata object in one table points to one that is 
used,
> directly or perhaps indirectly, in another table?)
I was hoping I didn't have to write a GC myself.  I think it is a 
hopeless cause, because in the general case it is beyond me.

> 
> In general, you might have C++ objects in lots of tables, all of 
which
> need to be freed in a particular sequence. So having a GC fallback 
for
> tables only pushes the problem back a level, while making the API 
more
> complex.
This is a very good point.  In the general case you are basically 
programming in C++, as far as memory management is concerned. In C++, 
at least the programmer can write a destructor to ensure that
an object(acting as a container) is notified when it is about to be 
deleted.  In the (container's) destructor, the programmer can manage 
the deletion of contained pointers in whatever sequence is required 
(perhaps it contains a tree of pointers and the tree needs to be 
traversed). All I'm asking for is the equivalent help from Lua 
(notification when a container, i.e table, is being collected, so the 
C++ pointers it contains can be disposed of correctly).

> 
> I grant that in your particular case, you may only have intra-table
> dependencies, so for you, having a table GC fallback might be 
enough for a
> simple solution. For others, just having userdata GC fallbacks is
> enough. From the API design point of view, it seems best to keep it
> simple.
> 
I like simple API too.  But it must also be sufficient.  The only 
reason it was removed from 3.2 is because you can mess up if you 
really wanted to.  I tried to argue that accidental misuse is not an 
issue, if the manual provided clear description and warning.  (I'm 
volunteering to write that part if it goes into 4.0 :).  For example, 
this is what is in the manual about the foreach construct : "The 
behavior of foreach is undefined if you change the table _t during 
the traversal."  Similar wording is enough to warn programmers of the 
potential dangers.

Please note that I'm not asking for anything more than what was in 
3.2.  Perhaps the code in 4.0 has changed in this area so that it 
becomes difficult to backfit ?

Cheers,
PYI