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
