Re: The Lua 5.1(work) GC

[Jamie Webb <j@...>]

On Tuesday 25 May 2004 21:04, Mark Hamburg wrote:
> I can certainly sympathize with the view point that pre-emptive
> multi-threading is more trouble than it's worth. On the other hand, on a
> multi-processor machine, it would seem almost mandatory. If Lua is the glue
> holding a system together, then presumably it also becomes the glue
> coordinating the work being done by the processors. To do this would seem
> to require a way to pass data structures across the processors -- i.e.,
> across threads -- and a shared Lua universe seems the simplest way to do
> so. (I say Lua universe to distinguish from lua_State which actually is
> synonymous with a Lua thread.) Do you have recommendations for some other
> scheme? How should messaging between Lua processes work?

I think I'd like to see something like this:

- A fork operation which creates a new, identical, independent state, with 
copy-on-write for tables. That is, the table would be 'owned' by both states 
as long as it wasn't written to, but would be duplicated by whichever state 
wrote to it first. Admittedly, that would mean an extra level of indirection 
for object references to deal with their addresses changing, but I'm sure 
that could be made reasonably efficient (and it makes a copying collector 
possible too, for people worried about memory fragmentation). Strings could 
be shared between states since they are constant, but each state would need 
its own strings table. GCed values would presumably need to store a reference 
count indicating how many states they are alive in.

- A message queue for each state, which can be written to by the others. The 
data passed could be any Lua value, with the same copy-on-write method used 
for tables (so message-passing of constant values would be very cheap). A 
'shared blackboard' would be nicer, but it doesn't seem possible without 
using critical sections or somesuch, and that certainly doesn't feel very 
Lua-ish. A possible implementation of that sort of thing on top of message 
passing might be to have a separate noticeboard thread to which objects could 
be posted and recovered.

- A new __clone metamethod for userdata, which would allow them to duplicate 
themselves in an orderly fashion. The default action would be for userdatas 
to be replaced with nils in the child state. This metamethod would probably 
have to be called on access (i.e. as soon as the userdata finds its way onto 
the stack) rather than on write in order to keep things consistent.

That should mean that locks are required only for operations which change 
object reference counts, and for the message queue.

-- Jamie Webb