Re: The Lua 5.1(work) GC

[Mark Hamburg <mhamburg@...>]

Thanks. That's interesting as a model but based on the README it's pretty
narrow on how data gets passed amongst tasks. One might be able to work
around that with table pickling I guess.

Mark

on 5/25/04 1:23 PM, Daniel Quintela at danielq@advancedsl.com.ar wrote:

> If you like the message-passing paradigm, you can try :
> http://www.soongsoft.com/LuaTask.zip
> 
> Daniel
> 
> ----- Original Message -----
> From: "Mark Hamburg" <mhamburg@adobe.com>
> To: "Lua list" <lua@bazar2.conectiva.com.br>
> Sent: Tuesday, May 25, 2004 5:04 PM
> Subject: Re: The Lua 5.1(work) GC
> 
> 
>> 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?
>> 
>> Mark
>> 
>> on 5/25/04 12:31 PM, Roberto Ierusalimschy at roberto@inf.puc-rio.br
> wrote:
>> 
>>>> I'm just getting ready to look at 5.1 (after I clean up some uses
>>>> of .n).  One thing I'm curious about is whether it does anything to
>>>> reduce the need to lock the Lua state when manipulating the stack.
>>> 
>>> No. We do not think that "real multithreading" in Lua (that is, several
>>> preemptive threads sharing a single Lua state) is really a good idea and
>>> so it is not high in our list of priorities. There are several options,
>>> such as coroutines (i.e., non-preemptive multithreading) or threads with
>>> independent Lua states ("Lua processes"). (One thing we are trying to
>>> improve is the ability to yield inside metamethods and for iterators.)
>>> 
>>> -- Roberto
>> 
>