[Python-Dev] Signals, threads, blocking C functions
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 Py_AddPendingCall, to postpone the job of handling a signal
> until a "safer" time.
> 5. The function Py_MakePendingCalls() should eventually get
> called at a "safer" time by user or python code.
> 6. It follows that until Py_MakePendingCalls() 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
> g_main_loop_run(), 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