On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
