Re: hook question

[Glenn Maynard <glenn@...>]

On Wed, Oct 11, 2006 at 09:13:56PM -0500, Rici Lake wrote:
> In general, Lua makes no attempt to allow you to simultaneously use the 
> same lua_State in two different OS threads. While Lua itself probably 
> will survive, the same cannot be said of any C function: imagine what 
> would happen if two OS threads both decided to do: lua_pushnumber(L, 1) 
> on the same L. That's clearly a non-starter: if you really need to use 
> the same lua_State in two or more OS threads, you'll need to provide a 
> synchronization mechanism external to the Lua core.

However, lua_sethook is special in that it's the interface you use to
jump in and interrupt a running Lua program.  It already is treated
specially, in that it's intended to be run async from a signal handler
for exactly this purpose, and that (unlike most--all?--other API entry
points) it doesn't lua_lock (since that could deadlock a signal handler).

Doing this from a thread is just as important; not every platform implements
anything like Unix signals (eg. which halt the application while they
run), but just about every one has something like threads.

I don't expect it to work in the general case; sethook from a signal
doesn't work in the general case, either.  (If I'm calling lua_sethook
already when the signal happens, it could result in an inconsistent
state.  If writes to any of the variables take multiple instructions,
it may even result in a corrupt state.)  I think a version of lua_sethook
that did a lua_lock (like the rest of the API) would safely allow
implementing timeout-breaks from a thread, though, which is the main
point here.

(As I mentioned before, I think it's already very safe to do that from a
thread, given the atomicity or ordering restrictions are met.  Adding
the lock should eliminate those restrictions.  Usual disclaimers as to
my lack of familiarity with the code apply, of course ...)

> With some limitations, it's reasonably easy to use different related 
> lua_States in different OS threads, and the synchronization mechanism 
> used by Lua (lua_lock and lua_unlock) is intended to make this 
> possible. However, Lua provides no mechanism to synchronize access to 
> shared mutable state; you would have to provide that yourself if it 
> were needed.
> 
> Use of the Lua registry is particularly problematic in this regard; 
> luaL_*ref is not threadsafe if used on the registry, and neither is 
> luaL_newmetatable.

I noticed those.  It's a roadblock to multithreaded Lua, at least for
my purposes.  (I'm also not sure about performance with the constant
locking and unlocking.)  Generally threading Lua would be extremely
useful to me, but I don't feel safe in taking that plunge just yet.

I'm interested in anyone else's experiences with threading Lua.  Note
that my need for it has nothing to do with performance, but that I
want to be able to load data--which calls Lua--in one thread, while
allowing rendering to be driven by Lua in another thread.  A global
Lua lock causes needless contention between the two, with eg. a lengthy
load causing rendering to freeze.

> (In practice, there are some issues with the fact that hooks are 
> state-specific, rather than being part of the global state; for 
> example, it makes it rather more difficult to use hooks to monitor Lua 
> scripts unless you forbid the scripts to use the coroutine library.)

Can you use luai_userstateopen to set a default hook, to propagate
any active hook into the new state (or if not, could that be made
to work)?

-- 
Glenn Maynard