Author pitrou
Recipients alex, haypo, jcea, meador.inge, neologix, pitrou, rbcollins
Date 2012-01-04.10:52:14
SpamBayes Score 2.32647e-12
Marked as misclassified No
Message-id <1325674262.3458.3.camel@localhost.localdomain>
In-reply-to <CAH_1eM0u5aMhGu3WnLa_CckJ_p48zsSHMpUqpaVj2w39XCLt4w@mail.gmail.com>
Content
> > That sounds like a good solution in the middle-term. Are there any
> > drawbacks? (apart from launching a thread)
> 
> Just to be clear: the approach I was suggesting is to have a resident
> thread dedicated to signal management, not to spawn a new one when
> needed. Another advantage is that we could mask signals in all threads
> except this one, and have a consistent cross-platform behavior with
> respect to signals+threads.

Hmm, but that would break single-threaded programs which expect their
select() (or other) to return EINTR when a signal is received (which is
a perfectly valid expectation in that case).

> However I see two drawbacks:
> - it seems that we want to allow building Python without threads
> support. In that case, this wouldn't work, or we would need the
> current implementation as a fallback, but this would complicate the
> code somewhat.

I don't know if that's still useful to build Python without threads. I
would expect most platforms to have a compatible threads implementation
(and Python probably can't run on very small embedded platforms).
Perhaps you can ask on python-dev.
History
Date User Action Args
2012-01-04 10:52:15pitrousetrecipients: + pitrou, jcea, haypo, rbcollins, alex, meador.inge, neologix
2012-01-04 10:52:14pitroulinkissue13697 messages
2012-01-04 10:52:14pitroucreate