From owner-freebsd-threads@FreeBSD.ORG Fri Jun 11 06:43:06 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 4F85C16A4CE; Fri, 11 Jun 2004 06:43:06 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10CA443D46; Fri, 11 Jun 2004 06:43:06 +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 i5B6gm6x027866; Fri, 11 Jun 2004 02:42:49 -0400 (EDT) Date: Fri, 11 Jun 2004 02:42:48 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086935359.85387.14.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu 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:43:06 -0000 On Thu, 10 Jun 2004, Sean McNeil wrote: > On Thu, 2004-06-10 at 23:03, David Xu wrote: > > I think there is a race in GC_suspend_handler, > > code between sem_post and sigsuspend has race, let me demostrate: > > > > Master : pthread_kill(slave1, SIGUSR1); > > Master : semwait > > Slave1 : sempost > > Master : semwait return > > Master : pthread_kill(slave, SIGUSR2); > > Master : pthread_kill(slave2, SIGUSR1); > > ... > > Slave1 : scheduler switched to slave1, found there > > is SIGUSR2 in pending set > > Slave1 : invoke SIGUSR2 handler withinsa_handler > > Slave1 : SIGUSR2 handler return > > Slave1 : sigsuspend SIGUSR2 > > because SIGUSR2 was already handled, it hangs > > in sigsuspend, and never return. > > > > It seems the code has the race bug. I think you should > > use sigaction and set additional mask for SIGUSR1. > > code looks like this: > > > > struct sigaction sa; > > > > sigemptyset(&sa.sa_mask); > > sigaddset(&sa.sa_mask, SIGUSR2); > > sa.sa_handler = GC_suspend_handler; > > sigaction(SIGUSR1, &sa, NULL); > > > > this code will block out SIGUSR2 in GC_suspend_handler, > > and when you call sigsuspend for SIGUSR2, it should return > > if there is SIGUSR2 pending or it SIGUSR2 comes later. > > Actually, what I think is happening now is that the sigaction for > SIGUSR2 is being called but the sigsuspend isn't being release. Because the handler is being called before sigsuspend() is hit. -- Dan Eischen