Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s

["Daniel P. Berrange" <berrange@redhat.com>]

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 <jamie@shareable.org> 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 :|