Re: another try at multithreading

[Mark Hamburg <mark@...>]

On Jun 22, 2008, at 1:15 AM, Asko Kauppi wrote:

> Userdata:
>
> - multiple considerations. GC, light or real userdata etc.  I am  
> perfectly fine with no userdata copying between states, unless  
> "killer" usage cases can be shown. Can they?

Userdata copying is definitely useful but it does need to be done with  
care. For simple types -- e.g., an array of floats stored in the main  
body of the userdata -- there isn't an issue. But when userdata is  
just a pointer to a bigger object, you either need to replicate that  
object as well or you need to implement something like reference  
counting. Either way, you run the risk of having data hang around in  
the other universes while waiting for the GC to trigger. This problem  
exists without multiple universes, but it gets worse with multiple  
universes. One partial solution beyond just running the GC more  
aggressively is to implement move semantics as well as copy semantics.

But I agree with the general thrust of asking what it means to  
transmit data between universes.

For example, if I transmit the same table twice, do I end up with one  
table or two in the destination? Ordinarily one probably says "two" if  
the transmissions are separate, but what about namespaces referenced  
as local variables from closures -- though probably in that case what  
one wants is a way to turn the table back into something that will  
invoke require in the destination universe.

I think the multi-threading answer for Lua is probably a mixture of  
the notion of allowing C code to yield control back to the scheduler  
while it executes together with support for running multiple processes  
in different universes and having efficient messaging between them. In  
fact, sending a message and waiting for a result become an ideal point  
at which to yield control back to a scheduler.

(That said, cooperative multitasking can make one grow complacent and  
one can forget that a particular construct may yield to the scheduler  
and that when it does so certain things may change out from under a  
piece of logic. For example, an entry in a database might get deleted  
even as another piece of code was taking action based on it and that  
other piece of code could be surprised when it went back to update the  
now missing entry.)

Mark