>As far as I know (and I have looked into it somewhat), the only
>portable way to combine signals and select/poll, with no race hazard,
>is to have the signal handler write to a pipe, and the pipe included
>in the select/poll set.

I assume the race hazard you're talking about is the possibility of
missing the signal. We discussed this before I submitted the patch
and its important to understand that the intent of _this_ patch is not
to provide a function where signals are never missed, but rather to
one where signals are _usually_ not missed. That is a big improvement
over what we have today, in which signals are _always_ missed. In
particular, it's useful for several applications I have in mind.

We discussed that it might be worse because someone engineering by
experimentation might be misled into thinking signals are never
missed. So my patch included some hard to ignore documentation
explaining exactly what function is offered.

I originally proposed a pselect()-based patch that would have closed the
window entirely. It's not portable, but again the idea was to improve,
not to achieve perfection, so systems without pselect() would continue
to have what they have today.

But then I found out I had read the code wrong and it would in fact
have been a regression because pselect() has that file descriptor
limitation that the existing code, which uses poll(), does not.

So then I lowered my sights and proposed a patch that can miss signals
in a brief window, but works with all file descriptors and on all systems
that have poll(), even if they don't have pselect(). The patch mainly just
removes the code to ignore EINTR. For those systems that do have pselect(),
it also does a signal blocking and unblocking thing in order to shorten
the window of missed signals.

That's the patch that was applied and just reverted.

In the original discussion it was also noted that the self-pipe trick
would be useful in a lot of cases where neither pselect() nor simply
respecting EINTR are, but the converse is also true and self-pipe is
significantly more costly to implement. Still, it would be a great
addition to libcurl in addition to the function of the current patch.

But I don't think any of this is the source of Yang Tse's objection.
Yang speaks of overhead and problems on systems that lack poll() and
select() (on which a bunch of new code executes even though it has no
effect), and, ironically, of the opposite problem: having different
"hearts" on different platforms.

I don't think the patch actually contributes anything to this latter
problem, though. Libcurl has (before patch), two entirely separate
hearts: one for systems that have poll(), and one for systems that
don't. I feel the pain of which Yang speaks because it is because of
this duplicity that my first proposal was a waste. I didn't realize
until I actually ran the code that I had designed a change to the
heart that _doesn't_ apply to my systems. All my work was essentially
ifdef'ed out!

So I'm looking forward to hearing about the problems. I'm willing to put
more work into making libcurl calls more interruptible.

-- 
Bryan Henderson                                   San Jose, California