As far as I understand it, the only ways to use Lua in a multithreaded environment are:|
1. define lua_lock() and lua_unlock() macros as mutexes (but this pretty much makes it single-threaded in effect)
2. use entirely independent lua_States in different threads, and ferry messages between them
messages can be serialized (e.g. Lanes) or converted to an intermediary format (e.g. ORB etc)
1) can be rejected in most cases, since the most of the benefits of multi-threading are lost
Having independent lua_States is the only alternative, since related states share their registry and more importantly share the garbage collector, which is clearly not thread-safe!
Perhaps there may be a way to produce a more efficient, lower-level serialization using the Lua internals (which would appear as a conversion to 'immutable' status), I'm not sure. There are many nontrivial issues however: function upvalues, tables with cycles, userdata, etc.
Regarding the fifo: I also think that a notion of Futures would be a useful addition to Lua: http://en.wikipedia.org/wiki/Future_(programming)
Something similar can be found in Helper Threads - did you look at that?
I've experimented with something similar for sharing C++ structures between threads; one thread is the owner and can modify the structure, other threads can only read. Still, only fixed-size structures (such as arrays) are safe in this context (safe but not necessarily usable...), some structures can be made usable with double-buffering, and care needs to be taken over the life-cycle of objects (e.g. proxies, reference counts or more advanced techniques).
On Apr 12, 2008, at 11:37 AM, Mildred wrote: