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 neologix
Recipients jcea, meador.inge, neologix, pitrou, rbcollins
Date 2012-01-04.02:51:09
SpamBayes Score 5.55112e-17
Marked as misclassified No
Message-id <>
In-reply-to <1325611700.3356.3.camel@localhost.localdomain>
> 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.

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.
- the thread would have to be respawned after a fork()

> The C version is quite recent, and there's a school of thought that we
> should always provide fallback Python implementations.
> (also, arguably a Python implementation makes things easier to
> prototype, although I don't think it's the case for an RLock)

Hmmm, I'm not convinced by this argument in this specific case: since
the C version is now the default, is faster and more reliable, can't
we drop the Python version?
Date User Action Args
2012-01-04 02:51:11neologixsetrecipients: + neologix, jcea, pitrou, rbcollins, meador.inge
2012-01-04 02:51:11neologixlinkissue13697 messages
2012-01-04 02:51:09neologixcreate