[Patches] [ python-Patches-960406 ] unblock signals in threads
SourceForge.net
noreply at sourceforge.net
Sat Jun 12 06:08:52 EDT 2004
Patches item #960406, was opened at 2004-05-25 22:00
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470
Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Langmead (langmead)
Assigned to: Nobody/Anonymous (nobody)
Summary: unblock signals in threads
Initial Comment:
This is a patch which will correct the issues some people
have with python's handling of signal handling in threads. It
allows any thread to initially catch the signal mark it as
triggered, allowing the main thread to later process it. (This
is actually just restoring access to the functionality that was
in Python 2.1) The special SIGINT handling for the python
readline module has been changed so that it can now see an
EINTR error code, rather than needing a longjmp out of the
readline library itself. If the readline library python is being
linked to doesn't have the callback features necessary, it will
fall back to its old behavior.
----------------------------------------------------------------------
>Comment By: Michael Hudson (mwh)
Date: 2004-06-12 11:08
Message:
Logged In: YES
user_id=6656
Here's a version of the patch that includes the new unit test
(oops!) which I've rewritten slightly.
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-11 17:02
Message:
Logged In: YES
user_id=29957
No - wait. Ignore that test_timeout error, it exists with a
clean checkout.
The inability to interrupt make testall, however is new with
this patch.
Linux Fedora Core 2.
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-11 16:58
Message:
Logged In: YES
user_id=29957
With this patch:
bonanza% ./python Lib/test/test_timeout.py
testBlockingThenTimeout (__main__.CreationTestCase) ... ok
testFloatReturnValue (__main__.CreationTestCase) ... ok
testObjectCreation (__main__.CreationTestCase) ... ok
testRangeCheck (__main__.CreationTestCase) ... ok
testReturnType (__main__.CreationTestCase) ... ok
testTimeoutThenBlocking (__main__.CreationTestCase) ... ok
testTypeCheck (__main__.CreationTestCase) ... ok
testAcceptTimeout (__main__.TimeoutTestCase) ... ok
testConnectTimeout (__main__.TimeoutTestCase) ... FAIL
testRecvTimeout (__main__.TimeoutTestCase) ... ok
testRecvfromTimeout (__main__.TimeoutTestCase) ... ok
testSend (__main__.TimeoutTestCase) ... ok
testSendall (__main__.TimeoutTestCase) ... ok
testSendto (__main__.TimeoutTestCase) ... ok
======================================================================
FAIL: testConnectTimeout (__main__.TimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_timeout.py", line 121, in
testConnectTimeout
"timeout (%g) is more than %g seconds more than expected
(%g)"
AssertionError: timeout (4.48679) is more than 2 seconds
more than expected (0.001)
----------------------------------------------------------------------
Ran 14 tests in 17.445s
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_timeout.py", line 192, in ?
test_main()
File "Lib/test/test_timeout.py", line 189, in test_main
test_support.run_unittest(CreationTestCase, TimeoutTestCase)
File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
run_suite(suite, testclass)
File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_timeout.py", line 121, in
testConnectTimeout
"timeout (%g) is more than %g seconds more than expected
(%g)"
AssertionError: timeout (4.48679) is more than 2 seconds
more than expected (0.001)
Also, with this patch applied, I can no longer kill a 'make
testall' with a ^C
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-06-11 15:18
Message:
Logged In: YES
user_id=6656
The patch didn't apply, so I've updated it (attached).
I see test_asynchat fail occasionally now, but don't know if that's
because of this patch :-(
Once I've sorted that out in my head, I think I'm going to check
this in.
----------------------------------------------------------------------
Comment By: Andrew Langmead (langmead)
Date: 2004-05-29 06:49
Message:
Logged In: YES
user_id=119306
Here is a reformatted version of the patch.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-05-28 15:25
Message:
Logged In: YES
user_id=31435
I agree that "busy" always should have been volatile -- once
again, good eye!
Python C style is basically K&R Classic, hard tab for
indentation, open curly at the end of the line opening a block
except for first line of function definition. Just make it look
like the other C code, but be careful to pick one of the .c
files Guido approves of <wink>.
----------------------------------------------------------------------
Comment By: Andrew Langmead (langmead)
Date: 2004-05-28 13:37
Message:
Logged In: YES
user_id=119306
Thank you for pointing me to PEP 7. I'll take a look at where I am amiss
and fix it up. For the change in ceval.c, I took a look at gcc's x86
assembly output of the file, and noticed that the optimizer was altering
the order of the busy flag test. Since busy is set from other concurrent
execution (other signal handlers), changing the variable to volatile told
gcc not to optimize accesses to the variable.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-28 09:54
Message:
Logged In: YES
user_id=6656
I haven't been able to test on MacOS X further, unfortunately.
The patch works on linux/x86 though (after fixing the
TabError :-) but this is with an NTPL kernel, so I didn't
have a problem anyway.
The C doesn't all conform to the Python style -- see PEP 7.
Can you fix that?
Why the change to Python/ceval.c?
After all that -- thanks a lot! I really want to get this
checked in ASAP so we can find out which platforms it breaks
at the earliest point in the 2.4 cycle.
----------------------------------------------------------------------
Comment By: Andrew Langmead (langmead)
Date: 2004-05-27 07:04
Message:
Logged In: YES
user_id=119306
It seems that at least OS X, sending the kill to the process schedules that
the receiving process will run the signal handler at some later time. (it
seems to be the only one to frequently run the signal handlers in the
opposite order than they were sent) This revised version of the test
seems to work better on OS X.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-26 19:41
Message:
Logged In: YES
user_id=6656
test_threadsignals hangs for me on OS X. Haven't done anything
more thorough than that yet...
----------------------------------------------------------------------
Comment By: Andrew Langmead (langmead)
Date: 2004-05-26 18:48
Message:
Logged In: YES
user_id=119306
I apologize that the missing patch.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-05-26 18:22
Message:
Logged In: YES
user_id=6656
There's no uploaded file! You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.
Please try again.
(This is a SourceForge annoyance that we can do
nothing about. :-( )
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470
More information about the Patches
mailing list