lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thu, Jul 11, 2013 at 4:06 PM, Sean Conner <> wrote:
> It was thus said that the Great Andrew Starks once stated:
>> Here are some assumptions that we are making:
>> 1: Unless we define `lua_lock` / `lua_unlock`, we need a mutex for
>> every shared access point, even for basic types, like numbers.
>   Yes, if multiple OS threads are sharing a Lua state.
>> 2: In these callback threads, if we stay away from shared access we
>> can do anything that we want, except possibly os.time / and
>> the other functions that the Reference Manual says might not be thread
>> safe.
>   Yes.
>> Most importantly, we're hoping that:
>> 3: This is a well-worn path and that other people use this strategy,
>> quite regularly.
>   Personally, I tend to give each OS thread its own Lua state, using a
> "no-share" model of computation.  Yes, it means copying data through a
> message, but the slowness of that approach isn't as slow as many people
> think [1].  I also think it's easier to reason about the resulting code.
>   -spc
> [1]     QNX is a message-based OS, and back in the 90s, a company
>         (disclaimer: I knew the owners) who sold X servers said their
>         *fastest* implementation was on QNX.

Thanks Sean. I think that your suggestion is where we'll end up. In
order to avoid tackling serialization and possibly a library (such as
ZMQ), and given that we're already dealing with a highly parallel API,
this felt like a smaller first step. We're *mostly* not sharing state,
at least. :)

Thanks for your comments!