Re: (ITS#5248) non-atomic signal variables

[h.b.furuseth@usit.uio.no]

[rearranging]
Howard Chu writes:

> The C standard defines "int" to be the most efficient machine word,
> and that is always atomic.

It does neither, that I can see.  Among other things because "most
efficient" is not well-defined.  E.g. by space or time?  Efficient with
which operations?  It's the recommended intent somewhere (the
Rationale?), but that must be subject to whatever other restrictions an
implementor faces.  (16+ bits, backwards compatibility, etc.)

And the compiler can choose between an atomic and non-atomic operation,
even with volatile.  Volatile guarantees a change is complete at a
sequence point.  Signals need not arrive at sequence points.  (C99
5.1.2.3p2,4.  You can download the standard with amendments free at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.)

Otherwise the standard would not have needed to define sig_atomic_t.

> sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero
> immediately, one entry, or two entries after the signal occurs isn't
> going to make any difference.

Well, I don't see any reason not to use it when the standard says so and
the change is trivial, even if we don't know of a real-life failure.
(E.g. if the compiler detects that the variable will not legally change
and optimizes it away, or if it is being read during a signal which
changes it so the result of the non-atomic read is a trap
representation.)

> Likewise, there's no issue with gotintr/abcan. The signal handler
> isn't armed until the writes are complete. Therefore whether it can be
> read atomically or not inside the handler is irrelevant, the value is
> constant.

So reading abcan is safe, but reading gotintr is not.  Read first half
before signal as 0, last half as -1.  Then the switch on it fails.

-- 
Hallvard