Charles-François Natali <neolo...@free.fr> added the comment: > 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13697> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
