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 pitrou
Recipients gregory.p.smith, hobb0001, jyasskin, pitrou, rnk
Date 2010-05-29.11:44:41
SpamBayes Score 0.0032538644
Marked as misclassified No
Message-id <1275133478.3124.48.camel@localhost.localdomain>
In-reply-to <1275101969.79.0.264603516238.issue8844@psf.upfronthosting.co.za>
Content
> I'm imagining (for POSIX platforms) adding some kind of check for
> signals when the system call returns EINTR.  If the signal handler
> raises an exception, like an interrupt should raise a
> KeyboardInterrupt, we can just give a different return code and
> propagate the exception.

Yes, this is what I'm proposing too.

> It also seems like this behavior can be extended gradually to
> different platforms, since I don't have the resources to change and
> test every threading implementation.

There is only one active POSIX threading implementation in 3.2, in
Python/thread_pthread.h.
(and the only non-POSIX one is for Windows)
History
Date User Action Args
2010-05-29 11:44:45pitrousetrecipients: + pitrou, gregory.p.smith, jyasskin, rnk, hobb0001
2010-05-29 11:44:42pitroulinkissue8844 messages
2010-05-29 11:44:41pitroucreate