>I would also like someone to clearly show us the benefits of using
>pselect() and ppoll() in libcurl

I assume you're talking about the benefits of using them instead of
select() and poll(). I'd like to get into that, but it isn't germane
to the present patch, because the patch doesn't do that.

I may have generated some confusion as to what this patch is -- The
subject line here suggests this patch is more about pselect() than it
actually is. I originally proposed replacing the select() in libcurl
with pselect(). I abandonned that idea when I discovered that the
select() in libcurl doesn't even execute on the systems I care about.

The patch in question leaves select() and poll() as they are, but
removes the logic that says if poll() fails with EINTR, just repeat it
(i.e. deliberately dismiss any interruption by signal). Instead, the
interruption percolates up to the higher level loop where it causes
the progress callback to get called before libcurl repeats the
poll()). The progress callback is the architected way for client code
to tell libcurl to stop waiting.

There _is_ a call to pselect() in there, only on systems that have
pselect (the POSIX one, not the short-lived prototypical one from
Glibc 2.0). But it's ancillary. It has a zero timeout and occurs
just before the normal poll(). It is meant to catch signals between
the most recent call to the progress callback and just before the
poll(), leaving only that tiny window where a signal can come in but
fail to stop libcurl from waiting. On a glibc system that has the
emulated pselect(), this has no effect -- same as a system with no
pselect() at all.

I moved some code around, and added many words of explanation of it to
make it easier to see how libcurl's select/poll logic works, so the
patch may make it look like the patch does more than it does.

I named a function curl_pselect(), because it relates to curl_select()
the way select() relates to pselect(), and that may also cause
confusion about what the patch does.

There are about a dozen ways I can think of (many already discussed in
the past few weeks) to add additional interruptibility to libcurl, and
I tried to structure things so they will fit in easily when someone
chooses to do the work. But the existing patch still looks like an
improvement over status quo to me.

-- 
Bryan Henderson                                   San Jose, California