| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Should we standardize on a type for signal handler flags? |
| Date: | 2017-06-04 23:21:39 |
| Message-ID: | 20170604232139.tqtr66g7qr7oapzt@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017-06-04 19:14:06 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > At the moment a number of flag variables set in signal handlers have
> > 'volatile bool' as type, others have 'volatile sig_atomic_t'. That's
> > kinda confusing. I think either is safe, but I think we should
> > standardize one of them.
>
> sig_atomic_t is more standards-conforming, I should think. I'm not sure
> if there are any current platforms where a store to a char variable
> wouldn't be atomic, but why live dangerously?
Well, we already have some variables that aren't actually booleans,
although I think all of them are only read not manipulated in signal
handlers (InterruptHoldoffCount etc). So one could argue that there's
no safety benefit in sig_atomic_t, because we're already using in other
places. 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'd be inclined to let the code continue to treat the variables as
> if they were bool, ie store "true" and "false" not "1" and "0"
> into them. That should be perfectly safe.
Indeed.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-06-04 23:26:41 | Re: Should we standardize on a type for signal handler flags? |
| Previous Message | Tom Lane | 2017-06-04 23:14:06 | Re: Should we standardize on a type for signal handler flags? |