Re: [HACKERS] Should we standardize on a type for signal handlerflags? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Should we standardize on a type for signal handlerflags?
Date
Msg-id 20170606173050.37xfjyovwshwemuv@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Should we standardize on a type for signal handler flags?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2017-06-06 13:07:57 -0400, Robert Haas wrote:
> > 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.

The signal handler case is the "weaker" one I think - you'll only ever
see the result of an entire CPU instruction, whereas cross-cpu
concurrency can allow another cpu to see state from the *middle* of an
instruction if not atomic.

- Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Should we standardize on a type for signal handler flags?