Re: hook question

[Rici Lake <lua@...>]

On 13-Oct-06, at 6:12 PM, Glenn Maynard wrote:

> But as for exposing them: you seem to be suggesting that I define 
> lua_sethook
> as: "this function must be locked by the user via lua_lock and 
> lua_unlock if
> called from a thread", and then to also say: "no other Lua API call 
> may be
> called between a lua_lock and lua_unlock", since if you do that (and 
> you
> don't happen to have recursive mutexes), it'll lock twice and 
> deadlock.  (And
> if you do have recursive mutexes, and the black box of Lua wants to 
> unlock
> the mutex, it won't work properly.)

Actually, I don't think I'm suggesting that you do anything.

My understanding is that the purpose of lua_lock() and lua_unlock() are 
to ensure that Lua is able to operate in a threaded environment, not 
that any particular Lua application be thread-safe. Basically, the lock 
is held at any moment when a garbage collection would be unsafe if 
triggered from another thread. As you imply, that's Lua's concern, and 
it's none of our business as application programmers. (However, Lua 
does not provide any definition of lua_lock() and lua_unlock() that are 
useful in a threaded environment, so someone has to take responsibility 
for that.)

Again, my understanding is that the intention is that even with a 
correct definition of lua_lock() and lua_unlock(), Lua provides no 
protection for using the same lua_State in more than one OS thread 
simultaneously. If you wish to do that, you must provide appropriate 
synchronization in your application, indepedent of anything Lua might 
do. lua_lock() and lua_unlock() are not intended for this purpose, and 
will not protect Lua from being corrupted by things you might do in 
such an application. (For example, read-only accesses to the stack are 
not protected by lua_lock(), but a call to lua_checkstack() from 
another thread might reallocate the stack while the read is taking 
place, which would surely produce unreliable results.)

lua_sethook() is advertised as being signal-safe. I'm prepared to trust 
Roberto's judgement that it is, although it seems to me that Posix 
would prefer that some of those fields be declared as volatile 
sig_atomic_t. However, I'm sure that Roberto has thought this through, 
and certainly I haven't noticed any problems with it.

Using lua_sethook() from a different OS thread to change the hook 
settings of a running lua_State would count as simultaneously accessing 
the same lua_State from two different OS threads, and thus fall into 
the category of "some synchronization mechanism is required which is 
not provided by Lua."

Now that we've gone through this loop a few times, I don't believe that 
lua_lock()/lua_unlock() are intended to be used for any purpose other 
than the purpose I alluded to above, nor do I believe that they would 
be an approrpriate mechanism. If I were to suggest anything to you, 
which would probably be pointless, it would be to use separate mutexes 
for each lua_State you needed to protect.

R.