This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bamby
Recipients Rhamphoryncus, bamby, exarkun, georg.brandl, gvanrossum, laca, movement, mstepnicki, pitrou, ross
Date 2009-12-15.07:42:16
SpamBayes Score 8.80747e-09
Marked as misclassified No
Message-id <>
Let me add my 2 cents. I understood the considerations about differences 
between Python code level interrupt handling and OS level interrupts. 

What I cannot get is why to preserve the handling of signals in the user 
threads on OSes like FreeBSD and Solaris. This functionality isn't used 
on Linux and Windows at all, as the interrupts on them are always 
delivered to the main thread. The patch simply assures the same behavior 
on the FreeBSD and Solaris, so why to keep things unpredictable when 
there is a way to solve the problem? Can anyone state what exactly 
purpose of not to make OS signal handling in Python predictable?

This bug report was created mainly because there is no easy Python code 
solution for this problem. The Python documentation clearly states that 
there is no user accessible Python functions that can modify per-thread 
signal mask, so it is currently impossible to solve the problem with 
just Python code. Modification of timeouts isn't vital solution in far 
too many real life situations.

BTW this patch is officially in the FreeBSD ports tree since Feb 27 2009 
and there is no complains on this patch since then.
Date User Action Args
2009-12-15 07:42:23bambysetrecipients: + bamby, gvanrossum, georg.brandl, exarkun, Rhamphoryncus, pitrou, movement, ross, laca, mstepnicki
2009-12-15 07:42:23bambysetmessageid: <>
2009-12-15 07:42:17bambylinkissue1975 messages
2009-12-15 07:42:16bambycreate