Re: Cygwin cleanup

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Noah Misch <noah@leadboat.com>
Date: 2022-08-04T06:07:35Z
Lists: pgsql-hackers
On Thu, Aug 4, 2022 at 5:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > It may be madness to try to work around this, but I wonder if we could
> > use a static local variable that we update with atomic compare
> > exhange, inside PG_SIGNAL_HANDLER_ENTRY(), and
> > PG_SIGNAL_HANDLER_EXIT() macros that do nothing on every other system.
> > On entry, if you can do 0->1 it means you are allowed to run the
> > function.  If it's non-zero, set n->n+1 and return immediately: signal
> > blocked, but queued for later.  On exit, you CAS n->0.  If n was > 1,
> > then you have to jump back to the top and run the function body again.
>
> And ... we're expending all this effort for what exactly?

I'd be almost as happy if we ripped it all out, shut down lorikeet and
added it to the list of fallen platforms.  I'd feel a bit like a
vandal, though.  My suggestion is a last-ditch idea for Noah (CCd)
and/or Andrew to consider, who (respectively) blocked this last time
and run lorikeet.  No plans to write that patch myself...



Commits

  1. Use unnamed POSIX semaphores on Cygwin.

  2. meson: Basic cygwin support

  3. meson: Mark PROVE as not required