Re: hook question

[David Jones <drj@...>]

On 12 Oct 2006, at 04:03, Rici Lake wrote:

> On 11-Oct-06, at 9:41 PM, Glenn Maynard wrote:
>
> > As for the VM releasing the lock: that's the purpose of  
> > luai_threadyield,
> > right?
>
> Ah, good point. I hadn't noticed that.
>
> However:
>
>   function forever() return forever() end
>
> :)
>
> As for sethook, if there were any doubt, wouldn't it be easier to  
> simply make the hook fields in lua_State atomic_t? Or is that not  
> guaranteed to exist?

Do you mean sig_atomic_t ?  That exists in ISO C, and "is the  
(possibly volatile-qualified) integer type of an object that can be  
accessed as
an atomic entity,eveninthe presence of asynchronous interrupts." (ISO  
9899:1999 section 7.14).  Basically writing to an sig_atomic_t value  
is pretty much the only portably safe thing you can do in a signal  
handler.  sig_atomic_t is probably okay for L->basehookcount (could  
be 16-bits though) and L->hookmask, but that still leaves the  
function pointer L->hook.  I think using sig_atomic_t for the integer  
fields (and not changing L->hook) would make it async-signal safe in  
the single-threaded case.

drj