From owner-freebsd-current@FreeBSD.ORG Thu Oct 1 12:53:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6BB810656A5 for ; Thu, 1 Oct 2009 12:53:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7098FC16 for ; Thu, 1 Oct 2009 12:53:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA03817; Thu, 01 Oct 2009 15:53:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4AC4A64E.7060201@icyb.net.ua> Date: Thu, 01 Oct 2009 15:53:34 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Justin Teller References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Signals and an exiting thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 12:53:38 -0000 on 30/09/2009 21:02 Justin Teller said the following: > We're trying to control one process from another process through > signals (I know, revolutionary ;-), and we've found that a signal > occasionally gets lost. The process we're signaling is > multi-threaded. It looks like the signal is lost when the kernel > decides to post the signal to a thread that is in the process of dying > (calling pthread_exit, etc). > > Is this expected behavior that we should just handle, or is it a race > in the kernel that should be/will be/already is fixed? > > It may be that a fix is already in current, and I just haven't found > it in my searches through the source code (I'm working off of source > code for an older 8.0 image). If it is fixed, I'd appreciate a > pointer to the code that fixes it. > > Thanks in advance for the help Do you allow all/arbitrary threads to catch signals? not sure if the following applies to your case, but for multi-threaded applications we usually designate a dedicated signal handling thread. sigwait(2), pthread_sigmask(2), etc -- Andriy Gapon