From owner-freebsd-current@FreeBSD.ORG Fri Oct 2 22:08:18 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 79ADB106566B for ; Fri, 2 Oct 2009 22:08:18 +0000 (UTC) (envelope-from justin.teller@gmail.com) Received: from mail-qy0-f192.google.com (mail-qy0-f192.google.com [209.85.221.192]) by mx1.freebsd.org (Postfix) with ESMTP id 33C3F8FC0A for ; Fri, 2 Oct 2009 22:08:17 +0000 (UTC) Received: by qyk30 with SMTP id 30so1697431qyk.7 for ; Fri, 02 Oct 2009 15:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=N6x1iKnxSynWQ++b35z7zh9ARqXR4zlzFr2t9+UVHu8=; b=SGwCOcMKz1HGMPh0CwCfIch5SVOhsO9g0Tbol6VLQGOqsTkdw3HDCh8W0nGguCPkWu WOivksqlFKGrzIKa4Q6mjYUtK2d0bKsmx4GfYeLaGUJKJTXZGl7d5cTyygZPegkDhV5c 8t1fic9kp8qmluzHjEcFDCxMzX9HH+hFgin20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pXegFLNxtEmUOu7nMB53cFQs0Yoo0tcQstTE5khjSCGHVGnd3JAfr+IQ5NM2z68XGT 9JFa0rBw/Mf5TH5VUlLbo3+r8ZA3COdvhmJhgIi7tuRHnJqFwx+1lamIrXxZRPOKZD2f YLCQo0M7n7QqD/YrATzrLDNPSOvHnnQs77Zkg= MIME-Version: 1.0 Received: by 10.224.41.84 with SMTP id n20mr1553289qae.205.1254521297395; Fri, 02 Oct 2009 15:08:17 -0700 (PDT) In-Reply-To: <20091002201213.GA16633@stack.nl> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> Date: Fri, 2 Oct 2009 15:08:17 -0700 Message-ID: From: Justin Teller To: Jilles Tjoelker Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , 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: Fri, 02 Oct 2009 22:08:18 -0000 On Fri, Oct 2, 2009 at 1:12 PM, Jilles Tjoelker wrote: --- snip --- > SIGKILL cannot be masked. Is it possible that a kill(SIGKILL) is > assigned to a dying thread and lost? > > (SIGSTOP cannot be masked either, but its processing is done by the > sending thread, so it should be safe.) > > I suppose that race can also occur in other uses of pthread_sigmask(). > If a thread masks a signal for a while, and that signal is assigned to > that thread just as it is executing pthread_sigmask(), it will only be > processed when that thread unblocks or accepts it, even though other > threads may have the signal unmasked or be in a sigwait() for it. > Signals sent after pthread_sigmask() has changed the signal mask are > likely processed sooner because they will be assigned to a different > thread or left in the process queue. > > POSIX seems to say that signals generated for the process should remain > queued for the process and should only be assigned to a thread at time > of delivery. > > This could be implemented by leaving signals in the process queue or by > tracking for each signal in the thread queue whether it was directed at > the thread and moving the process signals back at sigmask/thr_exit. > Either way I am not sure of all the consequences at this time. > > By the way, SA_PROC in kern_sig.c is bogus, because whether a signal is > directed at a specific thread depends on how it was generated and not on > the signal number. Fortunately, it is not used. > > -- > Jilles Tjoelker > Thanks for the helpful tips. Andriy's suggestion to only handle signals from a "sable" thread is a good one -- it would solve some problems. However, we did a little more investigation, and the SIGKILL example Jilles posted happens as well. We post a SIGKILL to a thread, and the thread goes away before it can kill the process. I like the idea of keeping signals like SIGKILL on the process queue so that it will be picked up with SOME thread. The other way is basically what Kostik suggested -- although I like the idea of copying the signal back to the proc queue there as well ... I'll play around with it and see what solves our problem, and I'll post back here with what I find out. -Justin