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.)"

So the unmasking and possible blocking on select must be done
atomically. And that is only feasible in kernel land.

Jan