Re: hook question

[Rici Lake <lua@...>]

On 16-Oct-06, at 2:44 PM, Roberto Ierusalimschy wrote:

> > atomic_t was my typo. As David and Roberto pointed out, I meant
> > sig_atomic_t, which is in posix.
>
> sig_atomic_t is part of the ISO C specification.

It is indeed. So it could be used...

Apparently, an asynchronous signal handlers can only:

"assign values to objects of type volatile sig_atomic_t" (from Plauger 
and Brodie)

That doesn't speak to the issue of out-of-sequence writes, but it 
should allow the definition of a signal-safe lua_enablehook().

My question is: are there any plausible use cases where that wouldn't 
be good enough? If not, perhaps it is better to go with that than to 
agonize about how to write a threadsafe lua_sethook(). If someone 
really needed a threadsafe lua_sethook(), it could be done by writing a 
hook handler which included the threadsafe code to call a secondary 
hook handler.