[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

[Adam Olsen]

On Dec 8, 2007 6:30 PM, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> On 09/12/2007, Guido van Rossum <guido at python.org> wrote:
> > Gustavo, at some point you suggested making changes to Python so that
> > all signals are blocked in all threads except for the main thread. I
> > think I'd be more inclined to give that the green light than the patch
> > using pipes for all signal handling, as long as we can make sure that
> > this blocking of all signals isn't inherited by fork()'ed children --
> > we had serious problems with that in 2.4 where child processes were
> > unkillable (except for SIGKILL).
>
> I don't think that solution works after all.  We can only block signals for
> certain threads inside the threads themselves.  But we do not control all
> threads.  Some are created by C libraries, and these threads will not have
> signals blocked by default, and also there is no 'thread creation hook' that
> we can use.

Note that new threads inherit signal masks from their creator.  It's
only threads created before loading python that are a problem.  For my
threading patch I plan to document that as simply something embedders
have to do.


> > I'd also be OK with a patch that
> > leaves the existing signal handling code intact but *adds* a way to
> > have a signal handler written in C that writes one byte to one end of
> > a pipe -- where the pipe is provided by Python code.
>
> I think this is most balanced approach of all.

Yeah, use the existing Handlers array to record which signals have
come in, rather using the byte passed through the pipe.

And I missed a problem in bug #1643738: Handlers[...].tripped should
be a sig_atomic_t, not int.


-- 
Adam Olsen, aka Rhamphoryncus