On 10/14/2016 04:05 PM, Tom Lane wrote:
I wrote:
Py_AddPendingCall is safe to call from a signal handler?  That would
be ... quite remarkable.

Yes, I believe it is. That's pretty much the raison d'ĂȘtre for Py_AddPendingCall(). I believe the Python interpreter itself implements signal handlers that way. If you set a signal handler with signal. So if you call Python's signal.signal(SIGINT, my_signal_handler) to set a "signal handler", my_signal_handler() won't be called from the actual signal handler. The actual signal handler just schedules the call with Py_AddPendingCall(), and the next time the Python interpreter is in a suitable place, i.e. not in the middle of an atomic operation or holding a lock, it calls the my_signal_handler().


I think that a much safer way to proceed would be, rather than asking
"how can I mess with the signal handlers", asking "how can I make my
python code act like it is sprinkled with CHECK_FOR_INTERRUPTS calls".

After some perusing of the Python docs I think it might be possible to
do this by setting up a trace function (cf Py_tracefunc()) that returns
a Python error condition if InterruptPending && (QueryCancelPending ||
ProcDiePending) is true.

I think Py_AddPendingCall() is more or less implemented by sprinkling calls similar to CHECK_FOR_INTERRUPTS, that check for "any pending calls?", over the Python interpreter code.

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to