Date: Thu, 6 Feb 1997 07:33:00 +1100 (EST) From: John Birrell <jb@cimlogic.com.au> To: ljo@Mcs.Net (Lars Jonas Olsson) Cc: hackers@freebsd.org Subject: Re: sigwait and threads? Message-ID: <199702052033.HAA02946@freebsd1.cimlogic.com.au> In-Reply-To: <199702051620.KAA25043@Mars.mcs.net> from Lars Jonas Olsson at "Feb 5, 97 10:20:35 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Lars Jonas Olsson wrote:
> The "Threads primer" book by Lewis and Berg recommends using sigwait
> for signal handling in multi-threaded applications. FreeBSD doesn't
> have a sigwait though. Should we get one? Or is another method for
> signal handling recommended?
According to 1003.1c, there should be a sigwait function in libc_r.
POSIX 1003.1c has a poor (IMHO) signal model. It is a committee design
used to justify entrenched positions. The rationale in P1003.1c/D10 says:
"Compromise reached:
The signal model of this standard contains:
(1) per-thread signal masks,
(2) per-process signal vectors,
(3) single delivery of each signal
The compromise satisfies as many of the sometimes conflicting goals as the
working group felt possible..."
It is (2) that I don't like. libc_r currently does not comply with that.
It does per-thread signal vectors. This will change when I can figure out
a way to allow the current behavio[u]r as an extension.
>
> I've got a multi-threaded application that currently runs on SCO
> UnixWare 2.1 that I also want to be able to run on FreeBSD. This
> application uses sigwait and no signal handlers.
Yuk. Oh well, I'll add a sigwait to the bunch of updates I'm working on.
>
> Jonas
>
Regards,
--
John Birrell CIMlogic Pty Ltd
jb@cimlogic.com.au; jb@netbsd.org 119 Cecil Street
Ph +61 3 9690 6900 South Melbourne Vic 3205
Fax +61 3 9690 6650 Australia
Mob +61 18 353 137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702052033.HAA02946>