lua-users home
lua-l archive

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


On Fri, Oct 02, 2015 at 09:57:09AM -0400, Patrick Donnelly wrote:
> On Thu, Oct 1, 2015 at 7:28 PM, William Ahern
<snip>
> > The increments aren't atomic, even on x86. It's probably benign, but also
> > unnecessary.
> 
> Why? A signal handler running for, say SIGINT, runs atomically for all
> SIGINT signals. Because the count is maintained per signal, the
> increments should be atomic.

My original thought was that two of the same signals could be delivered
concurrently. But reading the standard I see now that POSIX doesn't permit a
signal to be interrupted by the same signal,

	When a signal occurs, and func points to a function, it is
	implementation-defined whether the equivalent of a:

	signal(sig, SIG_DFL);

	is executed or the implementation prevents some
	implementation-defined set of signals (at least including sig) from
	occurring until the current signal handling has completed.

Still, hook might load the value in the middle of an increment by the signal
handler. But, yeah, either way it doesn't really matter which value it reads
as long as hook runs again. (And excluding theoretical hardware that exposed
some random value during the increment.)

But if signals are blocked in hook, a boolean 0 or 1 is sufficient, and the
shadowing is unnecessary. Plus, the code wouldn't risk invoking undefined
behavior by causing sig_atomic_t to overflow.