Re: prematurely killing threads in 5.0 beta

[RLake@...]

> 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?

It is a minor irritation that there is no easy way to empty a table and
still preserve object identity. I think there should be; from time to
time I have had to work around that by enclosing one table in another
table so that I can delete the inner table and still be able to keep
the outer table as a table key. Perhaps the most recent beta has this
feature, I have been a bit too busy to look at it -- it should not be
difficult to add and I think it would be useful.

Other than that, I can't see where it would be faster to "kill an object
and move on", unless that object were tying up some sort of external
resource, like maybe a database connection. In such cases, an explicit
"close" or "disconnect" or some such would be useful -- that would be
an object method, not a language feature, though. Of course, once that is
done, it is certainly true that the remaining guts are just sitting
around wasting space. If the Lua representation of the object were a
table, being able to quickly empty it would be useful.

I'm not sure if that applies to threads, though.

In any event, the hack I mentioned above always works. You can use
a trivial metamethod to defer all accesses from one table to another
one, in effect creating a proxy table which is empty (or you could
stash persistent information in it accessible through rawget.) Then
you are free to dump the metatable, and the proxy table retains only
what you absolutely need. No language modification at all, but some
slowdown on table references and a bit of space overhead.

Could you not do the same thing with threads? ... simply create a
proxy table with appropriate methods and the thread as a member?

R.