Date: Thu, 10 Jun 2004 23:29:19 -0700 From: Sean McNeil <sean@mcneil.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue Message-ID: <1086935359.85387.14.camel@server.mcneil.com> In-Reply-To: <40C94B1E.8030202@freebsd.org> References: <1086931276.38487.35.camel@server.mcneil.com> <40C94B1E.8030202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086935359.85387.14.camel>