signal handler priority issue

[David Xu]

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