[Python-Dev] Signals, threads, blocking C functions (original) (raw)

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Mon Sep 4 18:19:27 CEST 2006

Gustavo Carneiro wrote:

OK, let's review what we know about current python, signals, and threads:

1. Python launches threads without touching sigprocmask; 2. Python installs signal handlers for all signals; 3. Signals can be delivered to any thread, let's assume (because of point #1 and not others not mentioned) that we have no control over which threads receive which signals, might as well be random for all we know; 4. Python signal handlers do almost nothing: just sets a flag, and calls PyAddPendingCall, to postpone the job of handling a signal until a "safer" time. 5. The function PyMakePendingCalls() should eventually get called at a "safer" time by user or python code. 6. It follows that until PyMakePendingCalls() is called, the signal will not be handled at all! Now, back to explaining the problem. 1. In PyGTK we have a gobject.MainLoop.run() method, which blocks essentially forever in a poll() system call, and only wakes if/when it has to process timeout or IO event; 2. When we only have one thread, we can guarantee that e.g. SIGINT will always be caught by the thread running the gmainlooprun(), so we know poll() will be interrupted and a EINTR will be generated, giving us control temporarily back to check for python signals; 3. When we have multiple thread, we cannot make this assumption, so instead we install a timeout to periodically check for signals. We want to get rid of timeouts. Now my idea: add a Python API to say: "dear Python, please call me when you start having pending calls, even if from a signal handler context, ok?"

What can be safely done from a signal handler context is very limited. Calling back arbitrary Python code is certainly not safe.

Reliable asynchronous interruption of arbitrary code is a difficult problem, but POSIX and POSIX implementations botch it particularly badly. I don't know how to implement what you want here, but I'd endorse the comments of Nick Maclaren and Antony Baxter against making precipitate changes.

-- David Hopwood <david.nospam.hopwood at blueyonder.co.uk>

More information about the Python-Dev mailing list