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

["M. Warner Losh" <imp@bsdimp.com>]

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.

: If that's userspace (libc) code, then it is no good.  Nobody should
: ever have written crappy pselect() wrappers in userspace (i.e. Glibc),
: it just causes portable software to have to keep a whitelist of
: reliable pselect() platforms (i.e. not Linux) instead of just using
: it.  Same for crappy broken pread() and pwrite() wrappers.

Why is it no good.  What is the race here?  Is it just the oldmask
thing and multiple callers to select, or is it something else?  And if
it is the oldmask thing, why wouldn't multiple callers of pselect mess
it up depending on what order they have.  I must have missed the
original description of the race and why it matters..

Warner