Date: Fri, 19 Nov 1999 10:18:21 -0800 (PST) From: Kip Macy <kip@lyris.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-hackers@FreeBSD.ORG, scott@avantgo.com Subject: Re: EINTR problems with multithreaded programs. Message-ID: <Pine.SOL.4.05.9911191017170.3937-100000@luna> In-Reply-To: <199911191814.NAA02164@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > eischen@vigrid.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > 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?Pine.SOL.4.05.9911191017170.3937-100000>