lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



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.