Re: [HACKERS] Should we standardize on a type for signal handler flags?

On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund <andres@anarazel.de> wrote:
> 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.

I think that's a pretty good argument, really.  If there exists a
platform where only sig_atomic_t is safe to read from a signal
handler, then we already don't work on that platform.  Even saving and
restoring errno isn't safe in that case.  And if no such platform
exists, then I don't know what the benefit is of worrying about
sig_atomic_t at all.  If "int" is anyway going to be "volatile int",
then why should "bool" be written "sig_atomic_t" rather than "volatile
bool"?

> 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 don't think the issues are much different.  Presumably no CPU
delivers a signal halfway through a CPU instruction, so if we can rely
on a 4 byte store being indivisible from the perspective of some other
CPU, it seems fine to also rely on that being true in the signal
handler case.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company