Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJTKG-0004Bq-MU for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Aug 2022 05:23:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oJTKF-0002hm-Gl for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Aug 2022 05:23:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJTKF-0002ch-7U for pgsql-hackers@lists.postgresql.org; Thu, 04 Aug 2022 05:23:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJTKC-0000A7-R9 for pgsql-hackers@lists.postgresql.org; Thu, 04 Aug 2022 05:23:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2745N99K3338961; Thu, 4 Aug 2022 01:23:09 -0400 From: Tom Lane To: Thomas Munro cc: Justin Pryzby , PostgreSQL Hackers , Andrew Dunstan Subject: Re: Cygwin cleanup In-reply-to: References: <20220727064425.GG15006@telsasoft.com> <20220804033828.GK19644@telsasoft.com> Comments: In-reply-to Thomas Munro message dated "Thu, 04 Aug 2022 17:19:47 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3338959.1659590589.1@sss.pgh.pa.us> Date: Thu, 04 Aug 2022 01:23:09 -0400 Message-ID: <3338960.1659590589@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro 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? regards, tom lane