Date: Fri, 11 Jun 2004 02:42:48 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue Message-ID: <Pine.GSO.4.10.10406110242160.26412-100000@pcnet5.pcnet.com> In-Reply-To: <1086935359.85387.14.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406110242160.26412-100000>