linuxthreads/signals question

[GoatZilla]

This might be more of a general signals question, so apologies in advance.

I'm using the linuxthreads.old version of the threading code in uClibc, and
I seem to be getting a hang when using semaphores.

What appears to be happening is one thread is reaching __new_sem_wait, but
gets preempted between line 86 and when the actual system call to suspend
actually occurs (line 97).  By that point, it has checked the semaphore and
found that it's not available, and added itself as "waiting" for the
semaphore.

http://git.uclibc.org/uClibc/tree/libpthread/linuxthreads.old/semaphore.c#n59

The other thread then hits __new_sem_post, discovers another thread is
waiting for the semaphore and sends the signal to it.

The 'wait' thread then wakes up, but hasn't hit the suspend call yet.  It
eventually gets there, but then sleeps indefinitely because I guess the
previous signal, which was apparently an RT signal, was eaten or something.



Is this what's supposed to happen in this circumstance?  What should to
happen to the RT signal that goes to a thread before it's actually reached
its suspend call?  Or is this a bug with uClibc?




Thanks!