On Fri, Dec 22, 2017 at 1:23 AM, Gregg Reynolds <dev@mobileink.com> wrote:
> But I'm a little worried about threading. Using the lib involves callbacks, each of which is on a separate thread. I.e. you pass a cb to the send fn, and the engine, when it receives a response, passes control to the call back, with the incoming msg as an arg, but on a new thread.
I am not familiar with that framework, so I can only say a few general things.
> My understanding is that I would just need to create a new Lua state for each thread, to pass to the call back.
If you are completely sure that a given callback can only be called from a particular thread, or at least at can only be called once before it returns control, then this approach would work (0).
If, however, a given callback can be invoked by multiple threads without serialisation, then you will have to either (A) serialise access to the Lua stack or (B) use a multithread-safe Lua state. In case (A), care must be taken to serialise ALL kinds of access to the state, in case (B) you need to build your Lua library in a special way, which may or may not be possible depending on your needs to use third-party Lua libraries.
> Seems reasonable to me, but it also looks like one of those things that turn out to be much more complicated than they seem. For example, if the same callback can occur multiple times, can I save one Lua state per callback and reuse it?
It is not clear what "multiple times" and "save one Lua state" mean here.
> And what if I want to share some data across threads?
In case (0) or case (A), you would need something else to share data. The framework itself might provide means to that effect, check it out.
In case (B), all callbacks can use the same Lua environment concurrently, so sharing is natural.
