Date: Thu, 10 Jun 2004 22:08:06 -0700 From: Sean McNeil <sean@mcneil.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue Message-ID: <1086930486.38487.28.camel@server.mcneil.com> In-Reply-To: <Pine.GSO.4.10.10406110045190.3196-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10406110045190.3196-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2004-06-10 at 21:55, Daniel Eischen wrote: > On Thu, 10 Jun 2004, Sean McNeil wrote: > > > On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote: > > > > > > The critical section should prevent the signal handler > > > from being invoked. Put some printf()'s in after the > > > sem_post() and in the signal handler(). The signal > > > handler printf()'s should always occur after the sem_post(). > > > Plus, you shouldn't be getting that signal since it > > > should be masked until sigsuspend() is called. > > > > > > Is it getting past sem_post() and into sigsuspend() or not? > > > If it is getting past sem_post(), then I don't think that is > > > your problem. > > > > 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. > > Later, master calls pthread_kill with SIGUSR1 and waits on semaphore. > > other thread gets signal and calls sem_post. It yields the scheduler. > > Why is it getting SIGUSR1? It is waiting for SIGUSR2, not > SIGUSR1. You need to mask SIGUSR1 before the sem_post() and > until after the sigsuspend() on SIGUSR2. The problem is that it never gets to the sigsuspend. It yields right after the sem_post and gets interrupted again by another SIGUSR1. I see this because it never prints a message that is following the sigsuspend and the sig hander count is incrementing showing me that it is called 2 times before getting to the sigsuspend. > > master thread gets semaphore and continues on it's way. > > master thread calls pthread_kill with SIGUSR2 and keeps going. > > Finally, master scheduler is done and yields the scheduler. > > other thread gets to run now and then it goes into sigsuspend waiting > > for SIGUSR2, but it never gets it because it wasn't masked until > > sigsuspend is called. > > threads are all hung. > > > > The problem is that sem_post should not cause a reschedule of threads > > when inside a signal handler and it does. > > Nope, that is allowable. Please don't confuse signal safe with > "will not yield the CPU". Also, on SMP, there are not guarantees > regardless! OK. Then I suppose what is happening is that it is losing the SIGUSR2. But I don't really know why a signal handler would not be pushed to be high priority. Doesn't it seem logical that it should keep the scheduler past a sem_post? Perhaps that is the issue? Should a thread inside a signal handler have highest priority? > I'm not saying that there isn't a bug somewhere, but don't go > reading more into what the requirements of sem_post() are. I guess I read more into the comment than I should: /* * sem_post() is required to be safe to call from within * signal handlers. Thus, we must enter a critical region. */ I took this to mean (plus the critical enter/leave surrounding it) that sem_post should not yield the scheduler when inside a signal handler.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086930486.38487.28.camel>