Author pitrou
Recipients pitrou, python-dev, vstinner
Date 2011-04-17.23:59:23
SpamBayes Score 0.000260066
Marked as misclassified No
Message-id <1303084764.95.0.139736664942.issue11768@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 signal_handler() against reentrancy: 

diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c
--- a/Modules/signalmodule.c
+++ b/Modules/signalmodule.c
@@ -185,10 +185,12 @@ signal_handler(int sig_num)
         Handlers[sig_num].tripped = 1;
         /* Set is_tripped after setting .tripped, as it gets
            cleared in PyErr_CheckSignals() before .tripped. */
-        is_tripped = 1;
-        Py_AddPendingCall(checksignals_witharg, NULL);
-        if (wakeup_fd != -1)
-            write(wakeup_fd, "\0", 1);
+        if (!is_tripped) {
+            is_tripped = 1;
+            Py_AddPendingCall(checksignals_witharg, NULL);
+            if (wakeup_fd != -1)
+                write(wakeup_fd, "\0", 1);
+        }
     }
 
 #ifndef HAVE_SIGACTION
History
Date User Action Args
2011-04-17 23:59:25pitrousetrecipients: + pitrou, vstinner, python-dev
2011-04-17 23:59:24pitrousetmessageid: <1303084764.95.0.139736664942.issue11768@psf.upfronthosting.co.za>
2011-04-17 23:59:23pitroulinkissue11768 messages
2011-04-17 23:59:23pitroucreate