From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 05:53:17 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 BE4D116A4CE for ; Fri, 11 Jun 2004 05:53:17 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF5C43D4C for ; Fri, 11 Jun 2004 05:53:15 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 12ADDFD059; Thu, 10 Jun 2004 22:53:15 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38653-04; Thu, 10 Jun 2004 22:53:14 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 92EECFD01A; Thu, 10 Jun 2004 22:53:14 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086933194.38839.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 22:53:14 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com 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 05:53:17 -0000 On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > On Thu, 2004-06-10 at 21:55, Daniel Eischen wrote: > > > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > > > > > Here is what I see: > > > > > > > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore. > > > > other thread gets signal and calls sem_post. It yields the scheduler. > > > > > > This is fine as long as this thread doesn't get a signal > > > until after sem_post(). Being signal safe doesn't mean > > > that other threads can't be scheduled. > > > > > > > master thread gets semaphore and continues on it's way. > > > > master thread calls pthread_kill with SIGUSR2 and keeps going. > > > > > > 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.