Full_Name: Hallvard B Furuseth
Submission from: (NULL) (188.8.131.52)
Submitted by: hallvard
Some non-atomic variables are used both outside and inside signal handlers:
static int gotintr;
static int abcan;
static volatile int waking;
(used via WAKE_LISTENER in signal handler)
static int gotsig;
They need to be volatile sig_atomic_t.
That can be signed or unsigned char, so abcan must be set to some
#define in range 0..127 instead of -1.
Two more problems:
WAKE_LISTENER will not be correct anyway since it does '++waking' (not
atomic) and is called both inside and outside a signal handler.
The !NO_THREADS version is OK.
For that matter, behavior is only defined when the signal handler
_writes_ a volatile sig_atomic_t, not when it _reads_ it:
Dunno what the problem is, or if it is worse than variables
accessed by threads. I don't see anything to do about it either.
No. volatile is used in daemon.c, yes. It is not needed in clients/tools or
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.
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.
And of course...
The C standard defines "int" to be the most efficient machine word, and that
is always atomic.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/