> For a program I'm doing I need to use a single interpreter from multiple threads. I do not have problems in the normal case, just lock/unlock around usage, but some times I need to "reenter".
I would stay away from that.
If you can ensure that ostA, while waiting for a message, is not using Lua (except holding some memory for its Lua API stack) and ostB is not using Lua _in_any_way_ when and after it sends a message to ostA, then you have already achieved a fully synchronised execution of those threads with respect to Lua and no further locks can make it any safer. Those locks will probably only give you an inflated sense of security.
The emphasis on "in any way" is supposed to mean that all of the calls into Lua have returned in this thread and none will be made (till another cycle begins).
Your approach a/b, at first glance, looks like it might work and it is indeed similar to the paradigm used by Lua itself. The question is how generally robust that paradigm is. Imagine thread A does this:
lock(); push_value(); unlock(); do_something_not_touching_Lua(); lock(); pop_value(); unlock();
(where values are pushed and popped on the Lua API stack)
And thread B does this:
lock(); push_another_value(); unlock(); do_something_not_touching_Lua_2(); lock(); pop_value(); unlock();
What value each thread is going to pop? Do you even want to have to answer such questions?
Cheers,
V.
