1
votes

My server application running Lua scripts using LuaJit simultaneously. Each internal C++ script class stores own representation of the lua_State.

What I am trying to achieve is to implement some kind of the shared thread pool to avoid having a lot of the threads spawned from each running script ( I know Lua running coroutines and those are not real threads but some libraries do spawn actual threads, like cqueue doing C fork )

I know there are quite a few libraries like luv ( libuv bindings from luvit project ), turbo, cqueue and at this point I just wonder if I will use, for example, EventLoop provided by the libuv from the script A is it gonna be the same loop used in script B which requires the same library?

The problem lies in the fact that Lua script might have a long-running task while C++ code needs to call an event callback. Considering lua_State is not thread-safe it will block whole server thread.

1

1 Answers

0
votes

That all depends on the library being called.

You (more or less) can't load the same SO more than once, since by definition that's the same code. So if the library being called is not itself thread-safe (it has some library global state or whatever), then any code which depends on it will not be thread-safe without some form of explicit synchronization.

You will have to investigate the libraries being used by this code to see if they're relying on global state or not.