Re: Proposal for Signal Detection Refactoring - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal for Signal Detection Refactoring
Date
Msg-id 5951.1537837429@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Re: Proposal for Signal Detection Refactoring  (Chris Travers <chris.travers@adjust.com>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> And then within separate signal handlers things like:
> void
> StatementCancelHandler(SIGNAL_ARGS)
> {
>     [...]
>     signalPendingFlags |= PENDING_INTERRUPT | PENDING_CANCEL_QUERY;
>     [...]
> }

AFAICS this still wouldn't work.  The machine code is still going to
look (on many machines) like "load from signalPendingFlags,
OR in some bits, store to signalPendingFlags".  So there's still a
window for another signal handler to interrupt that and store some
bits that will get lost.

You could only fix that by blocking all signal handling during the
handler, which would be expensive and rather pointless.

I do not think that it's readily possible to improve on the current
situation with one sig_atomic_t per flag.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Proposal for Signal Detection Refactoring
Next
From: Michael Paquier
Date:
Subject: Re: Proposal for Signal Detection Refactoring