Re: safely buffering Lua data between (system) threads & lua_States?

[Javier Guerra <javier@...>]

On Saturday 16 September 2006 4:07 am, lists@grahamwakefield.net wrote:
> Aha! I didn't realise what lua_newthread did (I thought it was
> something to do with coroutines).  OK.  So if I understand correctly,

i think it does something to do with coroutines, one is built on top of the 
other... not sure how.

> I can have a root lua_State in one thread, create new lua_States from
> it using lua_newthread(), which will be managed in other threads, but
> create thread-safe interchanges between them using lua_xmove.

not exactly, lua_newthread() doesn't create a 'new' lua_State, it's 
a 'related' lua_State, it shares global storage with the original state; 
therefore it's important not to let two of them run at the same time with 
preemptive OS threads.  that's why you have to implement lua_lock and 
lua_unlock macros.  if done correctly it lets two related thread share a lock 
to manage the shared global storage (see LuaThread, by Diego Nehab)

> So lua_xmove is really creating copies from one stack to another.
> How are references resolved - are they deep copies?

lua_xmove just copies the value held at the stack.  if it's a reference (to a 
table, function, etc), it just copies the reference; just like parameter 
passing

> lua_newthread retains references to global data; how can this be
> thread safe if both the old & new threads (running in different
> system threads) can access them?  Are they also independent copies?

it's not thread safe unless you implement lua_lock/unlock; they're not copies


-- 
Javier

Attachment: pgprnkFXthv_1.pgp
Description: PGP signature