qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: andrzej zaborowski
Subject: Re: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s
Date: Wed, 5 Nov 2008 21:16:59 +0100

2008/11/5 Jan Kiszka <address@hidden>:
> M. Warner Losh wrote:
>> In message: <address@hidden>
>>             Jamie Lokier <address@hidden> 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.)"
>
> So the unmasking and possible blocking on select must be done
> atomically. And that is only feasible in kernel land.

To be exact, it *was* possible for glibc to implement a pselect free of races:
that is by using the same trick as your patch, i.e. making a pipe and
adding it to select()ed fd's and mangling the sigmask.

Cheers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]