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
-
Use unnamed POSIX semaphores on Cygwin.
- f2857af485a0 16.0 landed
-
meson: Basic cygwin support
- 79f7c482f674 16.0 landed
-
meson: Mark PROVE as not required
- ab72a31f6cc5 16.0 landed