Date: Fri, 19 Nov 1999 13:14:09 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: freebsd-hackers@FreeBSD.ORG, scott@avantgo.com Subject: Re: EINTR problems with multithreaded programs. Message-ID: <199911191814.NAA02164@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911191814.NAA02164>