Re: Proposal for Signal Detection Refactoring
От | Tom Lane |
---|---|
Тема | Re: Proposal for Signal Detection Refactoring |
Дата | |
Msg-id | 5951.1537837429@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal for Signal Detection Refactoring (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Proposal for Signal Detection Refactoring
Re: Proposal for Signal Detection Refactoring |
Список | 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 по дате отправления: