Re: ANN: Lua OS 0.4

[Gaspard Bucher <gaspard@...>]

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

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 ?

Gaspard