Charles-François Natali <neolo...@free.fr> added the comment: > I hope that this issue is not related to threads+signals. We got many > threads+signals issues on FreeBSD 6.
Yep. OpenBSD has a really specific pthread implementation (in user-space, using non-blocking I/O), so it might very well be "yet another threads+signals occurrence". @Rémi What happens if you run a code equivalent to test_sendall_interrupted on its own? I mean, if you try something like this: """ import signal, socket c, s = socket.socketpair() signal.signal(signal.SIGALRM, lambda x,y: 0) signal.alarm(1) c.sendall(b"x" * (1024**2)) """ If it works, you could try creating a dummy thread before setting up the signal handler, something like: """ t = threading.Thread(target=lambda: 0) t.start() t.join() """ And retry. The problem with all those interruption tests (like issue #12903) is that they'll break on many *BSD if another thread is running. Although in this specific case, I suspect that there are no threads running, and we're really encountering a kernel/libc bug (Victor, remember the "funny" bug on FreeBSD where kill(getpid(), <signal>) didn't deliver the signal synchronously after the first thread had been created?). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12905> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
