[Python-Dev] Signals, threads, blocking C functions
nmm1 at cus.cam.ac.uk
Thu Oct 12 16:10:27 CEST 2006
Sorry. I was on holiday, and then buried this when sorting out my
thousands of Emails on my return, partly because I had to look up the
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:
> >> | afaik the kernel only sends signals to threads that don't have them blocked.
> >> | If python doesn't want anyone but the main thread to get signals, it
> >> should just
> >> | block signals on all but the main thread and then by nature, all
> >> signals will go
> >> | to the main thread....
> > Well, THAT'S wrong, I am afraid! Things ain't that simple :-(>
> > Yes, POSIX implies that things work that way, but there are so many
> > get-out clauses and problems with trying to implement that specification
> > that such behaviour can't be relied on.
> Can you please give one example for each (one get-out clause, and
> one problem with trying to implement that).
2.4.1 Signal Generation and Delivery
It is extremely unclear what that means, but it talks about the
generation and delivery of signals to both threads and processes.
I can tell you (from speaking to system developers) that they
understand that to mean that they are allowed to send signals to
specific threads when that is appropriate. But they are as
confused by POSIX's verbiage as I am!
> I fail to see why it isn't desirable to make all signals occur
> in the main thread, on systems where this is possible.
Oh, THAT's easy. Consider a threaded application running on a
muti-CPU machine and consider hardware generated signals (e.g.
SIGFPE, SIGSEGV etc.) Sending them to the master thread involves
either moving them between CPUs or moving the master thread; both
are inefficient and neither may be possible.
[ I have brought systems down with signals that did have to be
handled on a particular CPU, by flooding that with signals from
dozens of others (yes, big SMPs) and blocking out high-priority
interrupts. The efficiency point can be serious. ]
That also applies to many of the signals that do not reach programs,
such as TLB misses, ECC failure etc. But, in those cases, what does
Python or even POSIX need to know about them?
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1 at cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
More information about the Python-Dev