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

Nick Maclaren nmm1 at cus.cam.ac.uk
Sat Sep 2 20:41:59 CEST 2006


"Gustavo Carneiro" <gjcarneiro at gmail.com> wrote:
> 
>   Oh, sorry, here's the comment:
> 
> (coment by Arjan van de Ven):
> | 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.

>   Well, Python has a broken design too; it postpones tasks and expects
> to magically regain control in order to finish the job.  That often
> doesn't happen!

Very true.  And that is another problem with POSIX :-(

>   Python is halfway there; it assumes signals are to be handled in the
> main thread.  However, it _catches_ them in any thread, sets a flag,
> and just waits for the next opportunity when it runs again in the main
> thread.  It is precisely this "split handling" of signals that is
> failing now. 

I agree that is not how to do it, but that code should not be removed.
Despite best attempts, there may well be circumstances under which
signals are received in a subthread, despite all attempts of the
program to ensure that the main thread gets them.

>   Anyway, attached a patch that should fix the problem in posix
> threads systems, in case anyone wants to review.

Not "fix" - "improve" :-)

I haven't looked at it, but I agree that what you have said is the
way to proceed.  The best solution is to enable the main thread for
all relevant signals, disable all subthreads, but to not rely on
any of that working in all cases.

It won't help with the problem where merely receiving a signal causes
chaos, or where blocking them does so, but there is nothing that Python
can do about that, in general.


Regards,
Nick Maclaren,
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 mailing list