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().

https://github.com/python/cpython/blob/4b71e63b0616aa2a44c9b13675e4c8e3c0157481/Python/ceval.c#L422

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:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to