From owner-freebsd-hackers Fri Nov 19 10:14:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5AA4C156AD for ; Fri, 19 Nov 1999 10:14:07 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA02164; Fri, 19 Nov 1999 13:14:09 -0500 (EST) Date: Fri, 19 Nov 1999 13:14:09 -0500 (EST) From: Daniel Eischen Message-Id: <199911191814.NAA02164@pcnet1.pcnet.com> To: freebsd-hackers@FreeBSD.ORG, scott@avantgo.com Subject: Re: EINTR problems with multithreaded programs. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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