Date: Fri, 11 Jun 2004 13:17:58 +0800 From: David Xu <davidxu@freebsd.org> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue Message-ID: <40C94086.7040505@freebsd.org> 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
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. > You are right here, I don't think any user visible pthread API should block scheduler to schedule other threads. However, I ever said that sem_wait may need to block out signal when it is holding internal semaphore mutex, because sem_post can be used in signal handler (POSIX explicitly wants this), if the current thread hold the mutex, and a signal arrrives, in signal handler, it calls sem_post(), sem_post try to hold the mutex again, it would be failure, then semaphore may be in inconsistent state. This is a corner case caused by sem_post can be used signal handler. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40C94086.7040505>