[ python-Bugs-944119 ] Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty

[SourceForge.net]

Bugs item #944119, was opened at 2004-04-29 11:05
Message generated for change (Comment added) made by lukem
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Levis (levis501)
Assigned to: Nobody/Anonymous (nobody)
Summary: Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty

Initial Comment:
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.


----------------------------------------------------------------------

Comment By: Luke Mewburn (lukem)
Date: 2004-08-22 11:08

Message:
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.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2004-05-23 17:58

Message:
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").

----------------------------------------------------------------------

Comment By: Steve Levis (levis501)
Date: 2004-05-19 05:55

Message:
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.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2004-05-18 19:05

Message:
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.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2004-05-18 19:03

Message:
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.

----------------------------------------------------------------------

Comment By: Steve Levis (levis501)
Date: 2004-05-06 03:08

Message:
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.

----------------------------------------------------------------------

Comment By: Steve Levis (levis501)
Date: 2004-05-06 02:59

Message:
Logged In: YES 
user_id=309698

I was apparently not running on a standard FreeBSD kernel. 
It's working now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470