From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:06:09 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52B1216A4CE for ; Fri, 11 Jun 2004 06:06:09 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0089A43D2D for ; Fri, 11 Jun 2004 06:06:09 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5B6686x020568; Fri, 11 Jun 2004 02:06:08 -0400 (EDT) Date: Fri, 11 Jun 2004 02:06:08 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086933194.38839.3.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 06:06:09 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote: > > > > > > > > It can't keep going if there is a possibility that it can > > > > send the same thread another SIGUSR2. > > > > > > I don't follow. Sorry. > > > > If the master thread does: > > > > for (i = 0; i < 4; i++) { > > pthread_kill(slave, SIGUSR1); > > sem_wait(&slave_semaphore); > > pthread_kill(slave, SIGUSR2); > > } > > > > You can see that there is a potential race condition where > > the slave thread gets SIGUSR1 and SIGUSR2 very close together. > > It is even possible to get them together in one sigsuspend() > > (if they are both unmasked in the suspend mask). > > > > You could fix the race by blocking SIGUSR1 from within > > the signal handler (like I described in my last email). > > I take it then that when a signal handler is invoked that it's signal > isn't masked while running. It isn't like a standard hardware interrupt > then. I'm trying as you suggest and will post results. Like I said before, it depends on the mask of the installed signal handler (sigact.sa_mask). You should use sigaction() and not signal() to get the desired behavior. You're other output looked strange. I was expecting the "restart" count to start at 1, not 2. -- Dan Eischen