From owner-freebsd-ports-bugs@FreeBSD.ORG Wed Jan 28 13:10:02 2009 Return-Path: Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530B51065673 for ; Wed, 28 Jan 2009 13:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2CC5C8FC22 for ; Wed, 28 Jan 2009 13:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0SDA1qS069145 for ; Wed, 28 Jan 2009 13:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0SDA1rK069144; Wed, 28 Jan 2009 13:10:01 GMT (envelope-from gnats) Resent-Date: Wed, 28 Jan 2009 13:10:01 GMT Resent-Message-Id: <200901281310.n0SDA1rK069144@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ports-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Andriy Pylypenko Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57BA1106567A for ; Wed, 28 Jan 2009 13:05:50 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 2BDA98FC21 for ; Wed, 28 Jan 2009 13:05:50 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0SD5nS4077449 for ; Wed, 28 Jan 2009 13:05:49 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0SD5nbh077448; Wed, 28 Jan 2009 13:05:49 GMT (envelope-from nobody) Message-Id: <200901281305.n0SD5nbh077448@www.freebsd.org> Date: Wed, 28 Jan 2009 13:05:49 GMT From: Andriy Pylypenko To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: ports/131080: Problem with signals in threads in Python X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 13:10:03 -0000 >Number: 131080 >Category: ports >Synopsis: Problem with signals in threads in Python >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jan 28 13:10:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Andriy Pylypenko >Release: FreeBSD 6.x and 7.x >Organization: Sippysoft Inc >Environment: i386, amd64, SMP and UP >Description: Almost a year ago I've created an issue in Python's bugtracker but the issue seems to be stuck since then so I'm sending the patch here in hope it could be included in ports collection. In short there is a problem in the Python that can be seen under FreeBSD and Sun Solaris but not under MacOSX or Linux. The problem is that when a Python program started a thread in a background, then it can be impossible to interrupt the program with Ctrl-C. The reason why this problem is FreeBSD specific is that the FreeBSD has different order of processing of signals. The signal handler under FreeBSD fires up in the context of the last started thread, while under Linux signals are processed in the main thread. It should be noted that both behaviors are standards conformant. This bug at Python bugtracker: http://bugs.python.org/issue1975 >How-To-Repeat: Here is an example script. Start it and try to interrupt by hitting ^C. import time import select from threading import Thread some_time = 6000000 # seconds class MyThread(Thread): def run(self): while (True): time.sleep(some_time) t = MyThread() t.setDaemon(True) t.start() while(True): select.select([], [], [], some_time) >Fix: To ensure that signal handler runs in the correct thread context the developer should use pthread_sigmask(). Initially the Python contained this code but starting from Python 2.4 it was thrown away. The attached patch restores the code that ensures correct execution context of the signal handler code. Patch attached with submission follows: Index: Python/thread_pthread.h =================================================================== --- Python/thread_pthread.h (revision 60447) +++ Python/thread_pthread.h (working copy) @@ -149,6 +149,7 @@ { pthread_t th; int status; + sigset_t set, oset; #if defined(THREAD_STACK_SIZE) || defined(PTHREAD_SYSTEM_SCHED_SUPPORTED) pthread_attr_t attrs; #endif @@ -178,6 +179,8 @@ pthread_attr_setscope(&attrs, PTHREAD_SCOPE_SYSTEM); #endif + sigfillset(&set); + SET_THREAD_SIGMASK(SIG_BLOCK, &set, &oset); status = pthread_create(&th, #if defined(THREAD_STACK_SIZE) || defined(PTHREAD_SYSTEM_SCHED_SUPPORTED) &attrs, @@ -187,6 +190,7 @@ (void* (*)(void *))func, (void *)arg ); + SET_THREAD_SIGMASK(SIG_SETMASK, &oset, NULL); #if defined(THREAD_STACK_SIZE) || defined(PTHREAD_SYSTEM_SCHED_SUPPORTED) pthread_attr_destroy(&attrs); >Release-Note: >Audit-Trail: >Unformatted: