Re: (ITS#5248) non-atomic signal variables
[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