On Dec 8, 2007 6:30 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: > On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
