Date: 20 Jun 1998 12:09:03 +0200 From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) To: smoergrd@oslo.geco-prakla.slb.com, hackers@FreeBSD.ORG Subject: Re: Signals in POSIX threads Message-ID: <xzpogvotmf4.fsf@hrotti.ifi.uio.no> In-Reply-To: John Birrell's message of "Sat, 20 Jun 1998 08:39:02 %2B1000 (EST)" References: <199806192239.IAA22404@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell <jb@cimlogic.com.au> writes: > POSIX threaded processes only have one set of signal handlers but a > thread specific signal mask. POSIX says that "at the time of generation, > a determination shall be made whether the signal has been generated > for the process or for a specific thread within the process". But without > each thread being able to choose a signal handler, it is not really > very useful. What bothers me is data sharing. Since I don't know which thread will run the signal handler, I don't know if it will be necessary to protect the data it uses with a mutex or if I can access it safely. I don't much like the idea of spin-waiting on a mutex lock inside a signal handler, either. If I set all threads except the main() thread to block a specific signal (say, SIGHUP), and install a handler for it, will that ensure that it runs in the main() thread or will it just disappear down a black hole nine out of ten times? > What are you doing that _needs_ signals? Nothing that strictly *requires* signals, but since the application is intended to be long-lived¹ I was considering catching SIGHUP and rereading the configuration file (and resetting some parameters which are auto-configured) when it occurs. -- One two, one two, one two. ¹ I'm working on real-time visualization of hydrophone data onboard seismological exploration vessels. --MAA16712.898337370/ifi.uio.no-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpogvotmf4.fsf>