Antoine Pitrou <pit...@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.
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. ---------- _______________________________________ 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
