Re: Asynchronous Strategy

[Sean Conner <sean@...>]

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 comapny
	(disclaimer: I knew the owners) who sold X servers said their
	*fastest* implementation was on QNX.