Re: [HACKERS] Should we standardize on a type for signal handler flags?

On 2017-06-06 14:45:37 -0400, Tom Lane wrote: > Andres Freund writes: > > A reasonable rule would actually be to only use [u]int32 and > > sig_atomic_t, never bool. > > Yes, I'd agree with that. Cool. I propose we change, once branched, the existing code using booleans, and

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Andres Freund writes: > A reasonable rule would actually be to only use [u]int32 and > sig_atomic_t, never bool. Yes, I'd agree with that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Robert Haas writes: > On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On Tue, Jun 6, 2017 at 2:24 PM, Andres Freund wrote: > 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On 2017-06-06 14:13:29 -0400, Robert Haas wrote: > On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Robert Haas writes: > On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund wrote: >> 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

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 >

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On Sun, Jun 4, 2017 at 7:21 PM, Andres Freund wrote: > 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Andres Freund writes: > On 2017-06-04 19:14:06 -0400, Tom Lane wrote: >> 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On 2017-06-04 19:14:06 -0400, Tom Lane wrote: > Andres Freund 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Andres Freund 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

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On Mon, Jun 5, 2017 at 8:00 AM, Andres Freund wrote: > 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