homepage

> 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?).