Re: [HACKERS] Should we standardize on a type for signal handlerflags? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Should we standardize on a type for signal handlerflags?
Date
Msg-id 20170604232139.tqtr66g7qr7oapzt@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Should we standardize on a type for signal handler flags?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Should we standardize on a type for signal handler flags?
Re: [HACKERS] Should we standardize on a type for signal handler flags?
List pgsql-hackers
On 2017-06-04 19:14:06 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > At the moment a number of flag variables set in signal handlers have
> > 'volatile bool' as type, others have 'volatile sig_atomic_t'.  That's
> > kinda confusing.   I think either is safe, but I think we should
> > standardize one of them.
> 
> sig_atomic_t is more standards-conforming, I should think.  I'm not sure
> if there are any current platforms where a store to a char variable
> wouldn't be atomic, but why live dangerously?

Well, we already have some variables that aren't actually booleans,
although I think all of them are only read not manipulated in signal
handlers (InterruptHoldoffCount etc).  So one could argue that there's
no safety benefit in sig_atomic_t, because we're already using in other
places.   We also already rely on int32 stores being atomic in other
parts of the code, although that's between processes not between signal
/ normal path of execution.


> I'd be inclined to let the code continue to treat the variables as
> if they were bool, ie store "true" and "false" not "1" and "0"
> into them.  That should be perfectly safe.

Indeed.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Should we standardize on a type for signal handler flags?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Should we standardize on a type for signal handler flags?