h.b.furuseth@usit.uio.no wrote:

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard

Some non-atomic variables are used both outside and inside signal handlers:

clients/tools/common.c: static int gotintr; static int abcan; servers/slapd/daemon.c: static volatile int waking; (used via WAKE_LISTENER in signal handler) slapd/slapcat.c: 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: http://groups.google.no/group/comp.std.c/msg/d01196111ce93615 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 slapcat.

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... http://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html#Atomic-T...

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