On 2017-06-06 14:13:29 -0400, Robert Haas wrote: > On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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. > > 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.
Don't think it's actually clear that errno is an integer - might very well be just a sig_atomic_t, which can contain values up to like 127 or so. I think the bigger point Tom was making is that we actually know an int4 is safe - otherwise we'd have crashed and burned a long time ago - but that that might be different for *smaller* datatypes because $platform doesn't really do smaller writes atomically (turning them into read-or-write operations either in microcode or assembly). Alpha, s390, pa-risc appear to have such behaviour cross-cpu - although that doesn't necessarily imply the same is true for handlers as well. A reasonable rule would actually be to only use [u]int32 and sig_atomic_t, never bool. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
