Subject: Re: Sempahore on NetBSD work or no ?
To: Nathan J. Williams <nathanw@wasabisystems.com>
From: David Maxwell <david@vex.net>
List: netbsd-help
Date: 01/27/2003 13:31:17
On Mon, Jan 27, 2003 at 01:21:14PM -0500, Nathan J. Williams wrote:
> 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.

I was under the impression that POSIX did not require that a signal
(such as SIGCHLD) be delivered to the thread that it would have, had the
thread been a process instead (i.e. a thread which called fork()).

In process space, the process that calls alarm(3) will get the SIGALRM.
In thread space, I thought POSIX said 'any thread can get the SIGALRM',
and the programmer has to deal with that.

> 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.

I _think_ Alan only needs that in context specific places - i.e. there's
a data structure that's per-fork() call, and if any thread that gets
messages about that child will update that structure, then he needs
thread-safe locking. If only the parent will get the messages, then
thread-safe locking won't be required. 

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
If you don't spend energy getting what you want,
	You'll have to spend it dealing with what you get.
					      - Unknown