[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (
> 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 

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/