Re: PG_SETMASK() archeology - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: PG_SETMASK() archeology
Date
Msg-id 20230120184910.GB4106863@nathanxps13
Whole thread Raw
In response to PG_SETMASK() archeology  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Fri, Jan 13, 2023 at 02:00:05PM +1300, Thomas Munro wrote:
> The reason we introduced PG_SETMASK() in the first place was to
> support one particular system that was very slow to adopt the POSIX
> signals stuff:  NeXTSTEP 3.x.
> 
> From some time in the dark age before our current repo begins until
> '97 we used sigprocmask() freely.  Then commit a5494a2d added a
> sigsetmask() fallback for NeXTSTEP (that's a pre-standard function
> inherited from '80s BSD).  In 1999 we added the PG_SETMASK() macro to
> avoid repeating #ifdef HAVE_SIGPROCMASK to select between them at each
> call site (commit 47937403676).  I have no personal knowledge of those
> systems; I wonder if it was already effectively quite defunct while we
> were adding the macro, but I dunno (NS 4.x never shipped?, but its
> living descendent OSX had already shipped that year).
> 
> Then we invented a bogus reason to need the macro for a couple more
> decades: our Windows simulated signal layer accidentally implemented
> the old BSD interface instead of the standard one, as complained about
> in commit a65e0864.

I found this very interesting.  Thanks for sharing.

> That's all ancient history now, and I think we might as well drop the
> macro to make our source a tiny bit less weird for new players, with a
> slightly richer interface.  Trivial patch attached.

+1, LGTM

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: "Takamichi Osumi (Fujitsu)"
Date:
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: "Takamichi Osumi (Fujitsu)"
Date:
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)