STINNER Victor victor.stin...@haypocalc.com added the comment:
It looks like pthread_mutex_lock() and pthread_mutex_unlock() are not reentrant
on some platforms (in some implementations of the pthread API).
Antoine: if I understand correctly your patch, if we have a pending signal, all
next
Antoine Pitrou pit...@free.fr added the comment:
Antoine: if I understand correctly your patch, if we have a pending
signal, all next signals will be simply ignored.
I don't think so, please re-read.
--
___
Python tracker rep...@bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
pthread_sigmask() can be used to avoid reentrant call,
but it has no effect on the second case: signal_handler()
called twice at the same time in two different threads.
Same problem if we use sa_mask field of sigaction() (e.g.
STINNER Victor victor.stin...@haypocalc.com added the comment:
I don't think so, please re-read.
Oh, I thought that Py_AddPendingCall() was used to store the pending signal.
But no, it asks Python main loop to check which signal has been trigerred, and
we can only do it once for all signals.
STINNER Victor victor.stin...@haypocalc.com added the comment:
Le lundi 18 avril 2011 à 10:40 +, STINNER Victor a écrit :
Attached patch should fix this issue:
- signal_handler() and PyErr_SetInterrupt() only call Py_AddPendingCall() on
the first signal (if is_tripped is zero): it
Changes by STINNER Victor victor.stin...@haypocalc.com:
Added file: http://bugs.python.org/file21703/signal_versionadded.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11768
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, I reproduced the bug.
[3021] test_threadsignals
test_signals (test.test_threadsignals.ThreadSignals) ... test_signals: acquire
lock (thread -1610559488)
test_signals: wait lock (thread -1610559488)
STINNER Victor victor.stin...@haypocalc.com added the comment:
The main thread was waiting test_signals() lock (signalled_all)
while it is was interrupted by a signal. The signal handler calls
Py_AddPendingCall() which blocks on acquiring pending_lock.
Oh, the main thread receives SIGUSR1:
Antoine Pitrou pit...@free.fr added the comment:
The signal handler calls Py_AddPendingCall() which blocks on acquiring
pending_lock.
It blocks in taking the mutex, not on waiting for the condition variable.
Otherwise it wouldn't block (microseconds = 0).
I think the solution is to protect
STINNER Victor victor.stin...@haypocalc.com added the comment:
The failure occurs also on Leopard:
--
[159/354] test_threadsignals
Thread 0x7fff7080f700:
File
/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_threadsignals.py,
line 53 in
STINNER Victor victor.stin...@haypocalc.com added the comment:
jseutter reproduced it after 112 and 49 runs on Snow Leopard using regrtest.py
-F -v --timeout=60 test_threadsignals command:
---
[ 49] test_threadsignals
test_interrupted_timed_acquire
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, the traceback only contains one thread, so send_signals() thread was not
created or failed very quickly (before its first print instruction).
--
___
Python tracker
New submission from STINNER Victor victor.stin...@haypocalc.com:
test_threadsignals hangs on x86 Tiger 3.x and PPC Tiger 3.x:
-
[279/354] test_threadsignals
Thread 0xa000d000:
File
/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py,
line 46 in
Roundup Robot devnull@devnull added the comment:
New changeset d14eac872a46 by Victor Stinner in branch 'default':
Issue #11768: add debug messages in test_threadsignals.test_signals
http://hg.python.org/cpython/rev/d14eac872a46
--
nosy: +python-dev
14 matches
Mail list logo
