Re: prematurely killing threads in 5.0 beta

["ackerman_wpi_edu <ackerman7@...>" <ackerman7@...>]

--- In lua-l@yahoogroups.com, Luiz Henrique de Figueiredo <lhf@t...>
wrote:
> >In my application, threads are handled entirely through C code, not 
> >Lua. I use the C functions, lua_newthread() and lua_resume(), to 
> >create and resume threads, rather than the Lua methods, 
> >coroutine.create and coroutine.resume. Assuming that threads are 
> >never referenced explicitly in my Lua code, what do I need to do on 
> >the C side of things to ensure that all references to a thread are 
> >gone?
> 
> The same thing you would do to make sure all references to a table
are gone,
> that is, the thread (which is now a Lua value, remember!) must not be on
> the stack, must not be the value of a global variable, nor a value
or key
> in a table or the registry, not an upvalue in any function, and so on.
> --lhf

This reminds me of something I was thinking about w.r.t. using GC in
games (aside from mere performance issues), such as prematurely
killing anything in Lua.

Since sometimes we know in advance of GC when an object is no longer
useful, I've always wondered whether it would be useful in Lua to
allow the "junking" of live objects.  What I mean by this is to remove
it's useful state and replace the internals with a "dummy" or empty
value.  For tables, you could simply swap the guts with a new (or
shared "dummy") table, and for threads, you could replace the
internals with a "do nothing and just return" harmless thread.

This naturally isn't any sort of replacement for GC or good
bookkeeping, but I could imagine scenarios where it would be
advantageous to kill an object and move on, rather than empty it
manually or ensure that it will be GC'd soon.  It's entirely possible
that this could be implimented within Lua, as I haven't really looked
into it, but even if it is, it could probably be faster (and thus more
useful) as a language feature.

Thoughts?