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

On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund <andres(at)anarazel(dot)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