From owner-freebsd-questions@FreeBSD.ORG Mon May 18 18:24:40 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56DF6106566C for ; Mon, 18 May 2009 18:24:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 437228FC0C for ; Mon, 18 May 2009 18:24:39 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJU00DGDR4MI620@asmtp020.mac.com> for freebsd-questions@freebsd.org; Mon, 18 May 2009 11:24:39 -0700 (PDT) Message-id: <0FC07847-8AEB-4728-8DAB-2F7FD2186E29@mac.com> From: Chuck Swiger To: Peter Steele In-reply-to: <7097313.721242663800853.JavaMail.HALO$@halo> Date: Mon, 18 May 2009 11:24:22 -0700 References: <7097313.721242663800853.JavaMail.HALO$@halo> X-Mailer: Apple Mail (2.935.3) Cc: #freebsd-questions Subject: Re: Why would a kill -2 not work? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 18:24:40 -0000 Hi-- On May 18, 2009, at 9:23 AM, Peter Steele wrote: > Under what circumstances might a "kill -2 nnn" not work. I have a > Python app with a signal handler configured to catch INT signals. It > seems to work fine, but we've recently noticed that after the app > has run for a while the kill -2 no longer works. This seems pretty > suspicious, perhaps indicating our app is misbehaving in some way. > What might cause the signal handler to stop working? The main reason might be that your process is already in another signal handler or is otherwise blocked in a system call and won't get the new signal until it completes the current situation. The amount of stuff you're allowed to do safely in a signal handler is pretty minimal-- you're better off setting a flag, returning from the signal handler, and having the next run past the main event loop or whatever check for the flag and handle things in a normal app context. If you try to do anything involving malloc() or s/printf, etc, you're running risks. "man sigaction" is likely to be informative.... Regards, -- -Chuck