Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> OK, but we certainly have code in signal handlers that does:
> int save_errno = errno;
> /* stuff */
> errno = save_errno;
> If that's not a signal handler changing an int, color me confused.
But it puts it back the same way at the end, so there's no visible issue
for mainline code. Even if the interrupted code were in the midst of
changing adjacent values, nothing bad would happen.
Perhaps it would help to give a concrete example of the type of hazard
you face with a non-interrupt-safe datatype --- which, for the present
purpose, is one that takes more than one CPU instruction to load or
store. (Andres is right that cross-process safety is a different and
stronger requirement.) Suppose we have a machine with no byte-wide
load/store ops, only word-wide, and the compiler has laid out four
bool variables a,b,c,d in the same word. If the mainline code is
trying to set d to 1, it's going to do something more or less like
ldw r2, ...address...ori r2, $1stw r2, ...address...
Now, if that sequence gets interrupted by a signal handler that tries to
change the value of a, b, or c, the change will be lost when we reach the
stw, because that's overwriting more than just the programmer-intended
target byte. On the other hand, there's no problem with the handler
*reading* any of those values --- it will see a consistent state. It also
wouldn't matter if it changed one of them and then changed it back before
returning.
In practice this would never be an issue for "errno" anyway, because int
is surely a datatype that can be loaded and stored in one instruction ---
the C standard actually defines int as being the machine's most
efficiently manipulatable type, so I think that's a pretty safe
assumption. But I'm not convinced the same is universally true for
"char".
regards, tom lane
