Robert Haas <robertmh...@gmail.com> writes: > On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane <t...@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, $1 stw 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers