Re: hook question

[Mike Pall <mikelu-0610@...>]

Hi,

David Jones wrote:
> I don't see how lua_sethook is safe when used in two different threads.

It's safe for the intended purpose. It's a timeout. You just want
the hook to be called as soon as possible. It doesn't matter
whether it's called before the next bytecode or the one after it.

> L->hook and L->base are modified in dependent ways, for example, and  
> no attempt is made to synchronise the updates.  What if one is using  
> an architecture with relaxed memory order?

[L->base ist not modified. Maybe you mean L->basehookcount.]

Any intermediate state caused by reordering of updates to the
memory fields in question is still safe. And only the final state
will cause a call to the hook. The code has been written with
great care (luaV_execute, traceexec, luaD_callhook).

It's basically an 'AND' function. You can flip the inputs (here:
individual memory words) from off to on in any order. It triggers
only when all changes have percolated.

> I'm pretty sure that lua_sethook isn't safe when used in a signal  
> handler either.

It's the same native thread, so memory ordering is not an issue.
Calling the hook setter asynchronously is safe. The worst case is
that the caller is interrupted during the 1st phase of the hook
check. This either means the check succeeds (with all fields set)
or fails (and succeeds the next time). No problem here either.

[
Of course any other access or update to the Lua state from
another thread or a signal handler is not safe. E.g. don't try to
use _any_ Lua API function other than lua_sethook().
]

Bye,
     Mike