Re: hook question

[Rici Lake <lua@...>]

On 11-Oct-06, at 9:13 PM, Rici Lake wrote:
> Finally, with respect to lua_sethook, there doesn't seem to me to be 
> any point providing a locking version, since that won't help with 
> signal-safety and, as I said earlier, it's the programmers 
> responsibility to ensure that the same lua_State is not being used 
> simultaneously in two OS threads. I suppose there is a question of 
> whether the existing lua_sethook is actually signal safe or not in a 
> multithreaded environment, in the face of the rather underspecified 
> interaction between signals and threads, but I would think the more 
> difficult issue in a signal handler is figuring out which lua_State's 
> sethook should be called.

Thinking about that for a few more minutes, I realized that one could 
eschew signals altogether in favour of a single alarm thread which woke 
up every so often and sethook'd any lua_State's registered with it. In 
that case, the thread safety of sethook would be an issue.

If it's not threadsafe as written (it looks ok to me, but as David 
Jones says, it's hard to say for sure), then it cannot be fixed by 
simply adding lua_lock and lua_unlock to it; that would make it 
unusable in a signal handler, and moreover would not solve the problem 
that was posed originally, because the entire VM runs inside the lock 
and therefore the sethook wouldn't acquire the lock until the VM 
released it (for example, by calling a CFunction), which might never 
happen.