Re: Proposal for Signal Detection Refactoring

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Chris Travers <chris(dot)travers(at)adjust(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal for Signal Detection Refactoring
Date: 2018-09-25 01:03:49
Message-ID: 5951.1537837429@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-09-25 01:13:11 Re: Proposal for Signal Detection Refactoring
Previous Message Michael Paquier 2018-09-25 01:02:09 Re: Proposal for Signal Detection Refactoring