Re: hook question

[Glenn Maynard <glenn@...>]

On Fri, Oct 13, 2006 at 06:01:42PM -0500, Rici Lake wrote:
> >You seem to be replying to me saying "they're not in the API" by saying
> >"they're not in the API".  :)
> 
> No, I mean they're not in the distribution *at all* except as #define's 
> to a no-op. It's your responsibility to define them (and presumably 
> expose them if you want to.)

They're in the distribution (regardless of that they're no-ops by default);
that seems unrelated.

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

I can't think of why that would be a better solution than to just expose
two lua_sethooks; one which behaves like the rest of the API (locking,
if locking is implemented), and one which is special and does not (like
lua_sethook now).  The only place you could safely use lua_lock/unlock
would be with sethook, anyway.  It's lua_sethook that's exceptional; all
I'm suggesting is that a regular, non-exceptional one be included as well.

-- 
Glenn Maynard