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

From Robert Haas
Subject Re: [HACKERS] Should we standardize on a type for signal handler flags?
Date
Msg-id CA+TgmoaaQTNur+0=P47L_QL4BdGmyyG_cu+biGBpFGoQ=nxysw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Should we standardize on a type for signal handler flags?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Should we standardize on a type for signal handlerflags?  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] Should we standardize on a type for signal handler flags?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jun 6, 2017 at 1:33 PM, Tom Lane <tgl@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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests