Message143586
> 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?). |
|
Date |
User |
Action |
Args |
2011-09-06 07:09:58 | neologix | set | recipients:
+ neologix, vstinner, rpointel |
2011-09-06 07:09:58 | neologix | set | messageid: <1315292998.26.0.369033267713.issue12905@psf.upfronthosting.co.za> |
2011-09-06 07:09:57 | neologix | link | issue12905 messages |
2011-09-06 07:09:57 | neologix | create | |
|