Johann Hibschman wrote:
Rici Lake wrote:
The coroutine mechanism is not implemented with threads, although
the API calls them threads (which they are, but not OS threads);
Lua threads are exposed as instances of a Lua_State, and those
Lua_States are related to each other. You probably don't want to
run those simultaneously in different OS threads, but it is
theoretically possible; the language does not provide any
synchronization primitives, though, so you need to implement your
own so that related Lua_States don't trod on each other's globals.
I keep wondering about this; wouldn't the garbage collector
require some synchronization, in order to avoid trouble with
multiple Lua-threads running in multiple OS-threads?
Yes, and Lua does that (if you configure it to).
There are macros lua_lock() and lua_unlock() which are supposed to
acquire and release a mutex (or something equivalent). Lua ensures
that the mutex is held during the execution of any Lua API function,
and during the execution of the Lua VM. While the VM is running, the
lock is periodically released in order to allow other related states
to run. During a garbage collection action, the lock is held.
