[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
