[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: safely buffering Lua data between (system) threads & lua_States?
- From: Javier Guerra <javier@...>
- Date: Sat, 16 Sep 2006 10:39:06 -0500
On Saturday 16 September 2006 4:07 am, email@example.com 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
> 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
Description: PGP signature