| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should we standardize on a type for signal handler flags? |
| Date: | 2017-06-06 17:30:50 |
| Message-ID: | 20170606173050.37xfjyovwshwemuv@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-06-06 17:33:38 | Re: Should we standardize on a type for signal handler flags? |
| Previous Message | Tom Lane | 2017-06-06 17:27:15 | Re: retry shm attach for windows (WAS: Re: OK, so culicidae is *still* broken) |