David Maxwell <david@vex.net> writes:


> So, if I understand correctly, Freeradius uses semaphores because 
> (a) it needs to implement thread-safe locking in signal handlers
> (b) The semaphore API is significantly simpler than pthread_mutex
> (c) The Linux pthreads (currently do, but) won't guarantee signal
> 	delivery to the right thread.
> 
> I believe our pthreads does guarantee signal delivery to the right
> thread (over and above the POSIX spec, which doesn't require that) - and
> Alan says that if that's the case, he can #ifndef __NetBSD__ all of the
> semaphore code in the Freeradius distribution. 

I'm not entirely sure how you're defining the "right thread" for
signal delivery here, but POSIX does have rules on the matter, and we
follow them - it's not "above and beyond" what POSIX specifies, though
it is beyond what LinuxThreads did for a long time. I understand it's
usually better now.

Also, if you need thread-safe locking in signal handlers, you have a
real problem.. the only locking or synchronization primitive that
POSIX gives you to use in a signal handler is sem_post(). Neither the
other sem_*() calls, nor any pthread_*() calls, can be used safely
inside a signal handler.

        - Nathan