[Python-Dev] Signals, threads, blocking C functions

[David Hopwood]

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>