That is not the way that Solaris or Windows NT handles it. However,
delivering the signal to all threads offers a lot more design flexibility.
-Kip
On Fri, 19 Nov 1999, Daniel Eischen wrote:
> > When using -pthread on FreeBSD3.3 to build a multithreaded program, I find
> > that signals are delivered to all threads (see attached program).
> > Specifically, if multiple threads are in blocking read calls, and a signal
> > is handled, they will all receive -1 from the read and EINTR in errno.
>
> If you don't want all threads to see the signal(s), then you
> have to block the signal(s) in each thread.
>
> > We're running MYSQL with a large number of connections (>1000), many of
> > which are idle at any given time (in a blocking read), and MYSQL uses alarm
> > signals in many places (it appears to be on a per-handled-query basis, but
> > I've not been able to pin this down quite yet). The net result is that
> > with many idle connections and many active connections, the idle
> > connections get a _lot_ of EINTR. By default, MYSQL takes 10 EINTR in a
> > row before dropping the connection - I've modified that upwards, but then
> > substantial amounts of CPU time are spent catching the EINTR and throwing
> > the thread back into the read (it's a relatively cheap operation - but
> > might happen a couple hundred thousand times a second).
>
> It sounds like MySQL isn't making sure that SIGALRM is blocked in
> all its threads.
>
> > I've tried using sigaction() in hopes of letting the system know that it
> > can restart the interrupted read(), but that doesn't seem to do the trick
> > in the attached program. Any other options?
> >
> > [Right now I'm seriously considering adding small sleeps to the EINTR case
> > in MYSQL. At least then all the threads won't wake up on every signal. I
> > know, I know, I should fix the use of signals, too, but that's going to
> > take a couple more weeks of becoming one with the code.]
>
> See /usr/src/lib/libc_r/test/sigwait/sigwait.c. FreeBSD delivers signals
> to each thread that has the signal unblocked. I believe this is part of
> the POSIX specified semantics for threads. You can use pthread_sigmask
> or sigprocmask within each thread to block each uninteresting signal.
>
> I have the POSIX standard at home, and I'll check to ensure we are
> handling signals in threaded programs correctly.
>
> Dan Eischen
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
