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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

That's an argument from false premises. The question here is what types
are safe for an interrupt handler to *change*, not what can it read.

Having said that, this is a good point:

>> 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.

That would license us to use int32 communication variables, but it still
doesn't mean that "bool" is safe.

In practice, the sort of architecture where bool would be a problem is
one that doesn't have narrower-than-word-wide memory access instructions,
so that changing a char-sized variable involves loading a word,
manipulating a byte within the word, and storing it back. I cut my
teeth on some machines like that, but I dunno if any still exist in
the wild.

regards, tom lane