Re: Asynchronous Strategy

[Andrew Starks <andrew.starks@...>]

On Thu, Jul 11, 2013 at 4:06 PM, Sean Conner <sean@conman.org> 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 / os.date 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!

-Andrew