Re: interleaved pcalls (multi-threading)

[Gaspard Bucher <gaspard@...>]

Thanks for the feedback, I fixed my implementation by using a new lua_State in the threads that are triggering callbacks (as explained on lua-users.org). 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

  end

  return msg + 5

end)

while not quit do

  worker:sleep(10)

end

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"... ;-)

Gaspard

On Sat, Jan 1, 2011 at 1:30 AM, David Manura <dm.lua@math2.org> wrote:

On Fri, Dec 31, 2010 at 5:53 PM, Gaspard Bucher <gaspard@teti.ch> 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 <gaspard@teti.ch> 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
manual:

 "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."