atom feed42 messages in org.freebsd.freebsd-threadssignal handler priority issue
FromSent OnAttachments
Sean McNeilJun 11, 2004 3:32 am 
Daniel EischenJun 11, 2004 4:18 am 
Daniel EischenJun 11, 2004 4:37 am 
Sean McNeilJun 11, 2004 4:41 am 
Daniel EischenJun 11, 2004 4:55 am 
David XuJun 11, 2004 5:01 am 
Sean McNeilJun 11, 2004 5:07 am 
David XuJun 11, 2004 5:15 am 
Sean McNeilJun 11, 2004 5:21 am 
Daniel EischenJun 11, 2004 5:29 am 
Sean McNeilJun 11, 2004 5:52 am 
David XuJun 11, 2004 6:00 am 
Daniel EischenJun 11, 2004 6:01 am 
Daniel EischenJun 11, 2004 6:05 am 
Sean McNeilJun 11, 2004 6:09 am 
Sean McNeilJun 11, 2004 6:25 am 
Sean McNeilJun 11, 2004 6:29 am 
Daniel EischenJun 11, 2004 6:41 am 
Daniel EischenJun 11, 2004 6:42 am 
Daniel EischenJun 11, 2004 7:15 am 
Sean McNeilJun 11, 2004 7:45 am 
Sean McNeilJun 11, 2004 8:04 am 
Sean McNeilJun 11, 2004 8:08 am 
Daniel EischenJun 11, 2004 8:10 am 
Daniel EischenJun 11, 2004 8:14 am 
Sean McNeilJun 11, 2004 8:16 am 
David XuJun 11, 2004 8:24 am 
Daniel EischenJun 11, 2004 8:26 am 
Sean McNeilJun 11, 2004 8:28 am 
Daniel EischenJun 11, 2004 8:32 am 
Daniel EischenJun 11, 2004 8:34 am 
Sean McNeilJun 11, 2004 8:37 am 
Sean McNeilJun 11, 2004 9:28 am 
David XuJun 11, 2004 2:42 pm 
Sean McNeilJun 11, 2004 5:42 pm 
Sean McNeilJun 11, 2004 6:08 pm 
Sean McNeilJun 11, 2004 6:15 pm 
David XuJun 11, 2004 10:44 pm 
Sean McNeilJun 11, 2004 11:18 pm 
David XuJun 11, 2004 11:33 pm 
David XuJun 12, 2004 1:01 am 
Sean McNeilJun 12, 2004 1:17 am 
Subject:signal handler priority issue
From:Sean McNeil (se@mcneil.com)
Date:Jun 11, 2004 3:32:11 am
List:org.freebsd.freebsd-threads

I'm working on kse support for gcc/gcj/gij and ran into an interesting problem with signals:

Each thread installs a signal handler for synchronization. This signal handler does a sem_post() to inform it has suspended then goes into a sigsuspend() loop waiting for a signal that has no handler attached to it. So we have

SIGUSR1 - signal handler attached to suspend the thread SIGUSR2 - no signal handler but waited on in sigsuspend() within the above handler.

When you want to have exclusive access, you loop through and stop each thread by sending the SIGUSR2 and wait on the semaphore it posts to. Then you do your thing. When done, you signal each thread with SIGUSR2.

The problem I'm seeing is that the signal handler doesn't have pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal is lost because it happens before the sigsuspend() is invoked.

I think there is something missing or not functioning in sem_post that should prevent the signal handler from losing the cpu. I see there is an enter/exit critical in there. Should that prevent it from context switching? It would appear not in that exiting a critical section will cause a yield.

Any help on figuring out how to fix this would be appreciated. Perhaps someone more familiar with kse can tell me how to go about changing it so that a signal handler cannot cause a yield. Perhaps something in _thr_sig_handler?

TIA, Sean