Subject: Re: Sempahore on NetBSD work or no ?
To: Nathan J. Williams <firstname.lastname@example.org>
From: David Maxwell <email@example.com>
Date: 01/27/2003 13:31:17
On Mon, Jan 27, 2003 at 01:21:14PM -0500, Nathan J. Williams wrote:
> David Maxwell <firstname.lastname@example.org> 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, email@example.comfirstname.lastname@example.org -->
If you don't spend energy getting what you want,
You'll have to spend it dealing with what you get.