[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Asynchronous Strategy
- From: Sean Conner <sean@...>
- Date: Thu, 11 Jul 2013 17:06:49 -0400
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
> 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 . I also think it's easier to reason about the resulting code.
 QNX is a message-based OS, and back in the 90s, a comapny
(disclaimer: I knew the owners) who sold X servers said their
*fastest* implementation was on QNX.