Issue944119
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-04-29 01:05 by levis501, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
failure_demo.py | levis501, 2004-04-29 01:05 | Reproduction of FreeBSD 4.8/4.9 signal issue | ||
failure_demo.c | levis501, 2004-05-18 19:55 | C version of failure_demo.py |
Messages (9) | |||
---|---|---|---|
msg20615 - (view) | Author: Steve Levis (levis501) | Date: 2004-04-29 01:05 | |
The attached python file reproduces a bug whereby Python does not receive alarm signals from FreeBSD 4.9. This also appears to be the case in FreeBSD 4.8, and may be related to the addition of HyperThreading in FreeBSD 4.8. If Python (either 2.2.3 or 2.3.3) is configured with -–without-threads before compiling, the bug does not exist. |
|||
msg20616 - (view) | Author: Steve Levis (levis501) | Date: 2004-05-05 16:59 | |
Logged In: YES user_id=309698 I was apparently not running on a standard FreeBSD kernel. It's working now. |
|||
msg20617 - (view) | Author: Steve Levis (levis501) | Date: 2004-05-05 17:08 | |
Logged In: YES user_id=309698 Ooops, again! I ran on the standard kernel but had python compiled --without-threads, so of course it worked. So, to make a long story short, the bug exists -- ignore my last post. |
|||
msg20618 - (view) | Author: Andrew I MacIntyre (aimacintyre) * | Date: 2004-05-18 09:03 | |
Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. |
|||
msg20619 - (view) | Author: Andrew I MacIntyre (aimacintyre) * | Date: 2004-05-18 09:05 | |
Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. |
|||
msg20620 - (view) | Author: Steve Levis (levis501) | Date: 2004-05-18 19:55 | |
Logged In: YES user_id=309698 I've uploaded failure_demo.c, which can be compiled with gcc -o failure_demo failure_demo.c -lutil. Written in C, the signal is properly delivered, and the test does not fail on either FreeBSD 4.7 or 4.9. |
|||
msg20621 - (view) | Author: Andrew I MacIntyre (aimacintyre) * | Date: 2004-05-23 07:58 | |
Logged In: YES user_id=250749 There are a few things I haven't been able to figure out with this problem, but I think this is what's going on: - on FreeBSD the read(2) call is not interruptable, as ptys appear not to be considered "slow devices" by the kernel (whether this behavior is *BSD specific I don't really know; ordinary files and pipes aresimilarly affected so forkpty() is just the messenger here); - Python's signal handling is documented to behave such that signal handlers only get invoked between Python VM opcodes. As the os.read() call is a single VM instruction, the nett effect is that the signal handler will not execute until the os.read() call/instruction completes... which it never does. This also affects other signals, such as SIGINT :-( The signal handler being invoked between opcodes explains why the C version works and the Python version doesn't. Using select.select() (or select.poll()) is one way of avoiding this trap, as both select(2) and poll(2) are interruptable (in addition to supporting timeouts directly). I expect this approach would also be considered to be generally portable. I haven't dug into why a single-threaded build avoids the Python VM opcode scheduling - I can only speculate that because the VM doesn't have any thread locking, it can actually execute the signal handler while the os.read() call is still pending. I don't expect there to be a practical solution to this, and so I'm suggesting that the bug be closed as "Won't fix" (read "Can't fix"). |
|||
msg20622 - (view) | Author: Luke Mewburn (lukem) | Date: 2004-08-22 01:08 | |
Logged In: YES user_id=135998 Please try the patch I provided in patch 975056; it fixes up various signal lossage on NetBSD & FreeBSD caused by python's intermixed use of signal(3) and sigaction(3). python wants non-SA_RESTART-able signals, yet signal(3) on *BSD traditionally sets SA_RESTART, and the mechanism that python uses to unset SA_RESTART when using sigaction(3) is flawed. It's quite possible that the os.read() non-interruptability you're noticing on FreeBSD is being caused by this issue. |
|||
msg20623 - (view) | Author: Steve Levis (levis501) | Date: 2004-12-15 21:05 | |
Logged In: YES user_id=309698 The system in question has been upgraded to FreeBSD 5.2 and this problem no longer exists. Thanks aimacintyre and lukem. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:03 | admin | set | github: 40196 |
2004-04-29 01:05:21 | levis501 | create |