Charles-François Natali <neolo...@free.fr> added the comment: > 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).
Yes, that's why I said "that"s another story" ;-) EINTR is really a pain, and relying on it to return from a syscall upon signal reception is a bad idea (certain OS restart syscalls by default - not select() though - and if the signal is received before you call the syscall, you'll deadlock). This would IMHO be the best way to go, but I know we can't reasonably change this now. > 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. There are another problems, for example it's very well known that signals and threads don't mix well (so for example you'd have to block all signals before spawning the new thread, and reenable them afterwards). I'm not sure it's worth the extra complication. I can still try to write a quick patch to see if it gets somewhere (and doesn't break test_threading and test_signals). The first and most simple thing we could do would be to nuke the Python version (and also the loggin hack at the same time): does that sound reasonable ? ---------- _______________________________________ 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