From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxnKM-0001S5-4I for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:42:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxnKK-0001PR-RT for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:42:01 -0500 Received: from [199.232.76.173] (port=58562 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxnKK-0001Oy-ID for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:42:00 -0500 Received: from mx1.redhat.com ([66.187.233.31]:43676) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxnKJ-0006eW-Vf for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:42:00 -0500 Date: Wed, 5 Nov 2008 18:41:50 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s Message-ID: <20081105184150.GV25523@redhat.com> References: <20081104113204.GA32125@shareable.org> <20081104.092231.-1384053398.imp@bsdimp.com> <20081105150042.GJ13630@shareable.org> <20081105.091015.232928302.imp@bsdimp.com> <4911E434.5020105@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4911E434.5020105@web.de> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Nov 05, 2008 at 07:21:40PM +0100, Jan Kiszka wrote: > M. Warner Losh wrote: > > In message: <20081105150042.GJ13630@shareable.org> > > Jamie Lokier writes: > > : M. Warner Losh wrote: > > : > : In other words, don't use pselect() if you might run on a kernel older > > : > : than 2.6.16, or on a host architecture which adds pselect() in a later > > : > : kernel version. Also, I wouldn't be surprised if older versions of > > : > : some BSDs have similar dodgy wrappers. > > : > > > : > Which ones have a good kernel implementation of it? FreeBSD's is > > : > currently approximately: > > : > > > : > if (!mask) > > : > _sigprocmask(mask, &oldmask); > > : > /* here */ > > : > select(); > > : > if (!mask) > > : > _sigprocmask(oldmask, NULL); > > : > > > : > I'm assuming that the problem is due to a signal arriving at /* here */. > > : > > : If that's _kernel_ code and the kernel behaves like Linux, it's not a > > : problem because signals don't affect the control flow until returning > > : to userspace, meaning the select() will return EINTR. > > > > It is currently user level code, and I'm looking at moving it into the > > kernel, but I need to understand the race being talked about here. > > From the Linux man page on [p]select: > > "The reason that pselect() is needed is that if one wants to wait for > either a signal or for a file descriptor to become ready, then an atomic > test is needed to prevent race conditions. (Suppose the signal handler > sets a global flag and returns. Then a test of this global flag followed > by a call of select() could hang indefinitely if the signal arrived just > after the test but just before the call. By contrast, pselect() allows > one to first block signals, handle the signals that have come in, then > call pselect() with the desired sigmask, avoiding the race.)" There's another good expanded description on LWN too: http://lwn.net/Articles/176911/ Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|