Subject: Re: Sempahore on NetBSD work or no ?
To: Nathan J. Williams <email@example.com>
From: Zoltan ZSIDO <firstname.lastname@example.org>
Date: 01/28/2003 20:22:15
On 28 Jan 2003, Nathan J. Williams wrote:
> Date: 28 Jan 2003 14:08:28 -0500
> From: Nathan J. Williams <email@example.com>
> To: Zoltan ZSIDO <firstname.lastname@example.org>
> Cc: David Maxwell <email@example.com>, Jason R Thorpe <firstname.lastname@example.org>,
> Daniel Dias Gonçalves <email@example.com>,
> firstname.lastname@example.org, email@example.com
> Subject: Re: Sempahore on NetBSD work or no ?
> Zoltan ZSIDO <firstname.lastname@example.org> writes:
> > Sorry I was amiguous. Using DEC's and HP's implementation You will not
> > suffer from select(2) caused problems. I'v seen this 'problem' only on
> > Solaris. The compliancy is about threaded signal handling. The
> > specification doesn't specify that the issuer of an alarm(2) call will be
> > signalled by the SIGALRM. It says only, that the signal will be delivered
> > to the process, so the next thread which is capable of handling this
> > signal will catch it or the process will be killed if no one thread
> > willing to catch it. All of the mentioned implementation conform to this
> > specification, but - as an undocumented feature - on OSF/1 and HP-UX it
> > will be delivered to the issuer thread always, on Solaris this will not be
> > garantied.
> Ah. This is easily handled by the application, though; block SIGALRM
> in the threads that are calling select(). I would say that in general,
> in a threaded universe, one should call pthread_sigmask() first and
> ask questions later.
Initially You will block ALRM in all thread (issuing the
pthread_sigmask(2) in the main thread sufficient since the per thread
signal mask is inherited by the created threads.) That is clear, but if
You issue the following steps in 2 thread, You will have 2 thread
waiting for ALRM independently from each other between step 2 and step 4:
1, block ALRM
2, enter select()
3, ALRM unblocked by select internally. (programmer has no control over
it since the issuer thread blocked by select()...)
4, return from select()
5, block ALRM again.
I think this is how Solaris do this internally when using alarm() to
mimic real world select().