Re: ANN: Lua OS 0.4

[Graham Wakefield <wakefield@...>]

On Aug 18, 2011, at 1:48 AM, Gaspard Bucher wrote:

> 
> 
> On Tue, Aug 16, 2011 at 2:46 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> > There are no locks in Lua OS. My model also not threading in the
> > classical sense (different threads working on the same data - the
> > model that leads to the well-known problems). I once held a talk about
> > the evils of multithreading, so I very clearly am sure to avoid that.
> >
> > The model is basically: event loops (on the sandbox level) plus
> > communicating processes (on the next-higher level).
> >
> > Thus there is never any concurrent action on the same data. Each
> > strain of execution has its own data. All communication is by message
> > passing.
> 
> Great!
> 
> -- Roberto
> 
> 
> This is exactly what LuaAV and Lubyk do (no concurrent execution on the Lua state). It is the second time I hear praise of the coroutine based model and I do not see why using a Lua scheduler/event loop is any better or even different from using the OS for scheduling through the use of a mutex:
> 
> A. coroutine model (LuaAV, Lua OS)
> 
> 1. needs an explicit event/scheduling loop in Lua
> 2. needs an inbox
> 3. needs a mutex on the inbox to get/post messages from external processes

Just to be accurate:

LuaAV doesn't have an explicit scheduling loop in Lua; the main loop is in C (driven from the OS main loop), but it does maintain a list of temporally scheduled tasks (including both Lua coroutines and C functors) within that loop. This is so that we can mix Lua and non-Lua processes into a temporally deterministic scheduling loop, which is important for our needs. Many other system events are handled in this same loop, avoiding the need for locking. In general we handle network input through user-driven non-blocking polling, so that we can precisely control the state of Lua when the effects of a received message occur.

LuaAV doesn't have a mutex on the inbox - this inbox is only used to communicate with one other thread (the audio process) so a pair of lock-free time-stamped FIFOs are used. 

> 
> B. mutex model (Lubyk)
> 
> 1. needs a mutex to enter the Lua state
> 2. needs to release mutex while idle in C space (receiving from socket/zmq/os callback)
> 
> Both models imply the use of a mutex per Lua state (for the inbox or the whole state) but from my understanding model "B" is more powerful because:
> 
> 1. it let's you implement model "A" without changing any of the C API (just post a message in an inbox instead of running the code).
> 2. it can cope with os callbacks that cannot transfer execution to another thread (OpenGL).
> 
> Are there any reasons why people choose the coroutine approach apart from "mutex" sounding like a swearword and "coroutine" like pillow talk ?

In our case, deterministic ordering of events, and precise user control of the Lua state when external effects occur.