lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Thanks for the feedback, I fixed my implementation by using a new lua_State in the threads that are triggering callbacks (as explained on This solved the strange errors I had and enables servers like this:

-- reply server
server = zmq.Rep("tcp://*:8894", function(msg)
  if msg == nil then
    quit = true
    return 0
  return msg + 5

while not quit do

I know Lua can be compiled with a lock to protect the internals in case multiple threads run in parallel, but I like the global lock to protect the application itself: it makes many things easier. Having the lock is a little like the coroutines: you choose when you "yield"... ;-)


On Sat, Jan 1, 2011 at 1:30 AM, David Manura <> wrote:
On Fri, Dec 31, 2010 at 5:53 PM, Gaspard Bucher <> wrote:
> thread A --> pcall(1) --> in Lua --> in C (unlock, sleep) ... wait for lock
> . .........lock --> end pcall(1)
> thread B ... wait for lock ............... lock, pcall(2) --> in Lua --> end
> pcall(2), unlock
> Is this ok ? If it is not, how can I keep track of multiple "paths" into the
> application ?

If I understand correctly, you have different preemptively multitasked
OS threads using Lua (e.g. via lua_pcall), but these uses are
serialized via a mutex lock around each use to ensure that only one
thread is using Lua at a time.  That is fine.  In fact, if these
threads are not accessing *independent* Lua states (e.g. obtained via
multiple calls to lua_newstate), then these locks can be necessary,
and each lock should surround not just the lua_pcall but probably all
Lua C API calls used so that each complete set of Lua C API calls is
accessed by only a single thread.  Other than that, there's nothing in
Lua that depends on a particular thread running it at a time, except
maybe when Lua in turn calls some C code if that C code is not thread
safe.  Such C code includes the C standard library--so you'd want a
thread-safe version of the C standard library--and any lua_CFunction's
of your own you inject into Lua.

On Fri, Dec 31, 2010 at 6:35 PM, Gaspard Bucher <> wrote:
> I have found this post from february 2010 saying that it should be ok, as
> long as I use a new thread (created with lua_newthread) as Lua context and
> only use it for the callback.

Careful: That's talking about "threads" as in Lua states/coroutines,
not OS threads as I think you're using.  From the Lua References

 "The type thread represents independent threads of execution and it
is used to implement coroutines (see §2.11). Do not confuse Lua
threads with operating-system threads. Lua supports coroutines on all
systems, even those that do not support threads."