Re: interleaved pcalls (multi-threading)

[David Manura <dm.lua@...>]

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