>... a flawed emulation that fails occasionally is pretty useless for
>robust software.

I think it's very useful, when you imagine the broad spectrum of ways
it might be used. I personally have several uses planned for it, in
which libcurl respecting signals some of the time is better than
libcurl ignoring them all the time. (Think about a person typing
control-C. One out of a million times, select() sleeps anyway and
doesn't wake up until 1000 ms later).

I agree that it creates a problem for the person who programs by
reverse engineering libcurl: try a signal once, see that it interrupts
the wait, assume that it always will. But that mistake is almost a
zero risk, since that programmer has to create a progress function
that returns the proper return code, so probably will peruse the
documentation or the header file, and there will be a warning there
that the method is not reliable.

The self-pipe trick would be another good option to have available.
In the self-pipe trick, the signal handler writes a byte to a pipe.
The select() includes a file descriptor for that pipe in its list of
files it's waiting for. That way, even if the signal happens before
select() begins, it will still stop select() from waiting. In fact,
the process that wants to interrupt libcurl might just use the pipe
instead of a signal to begin with.

This is in another league of code change, though, since it requires
adding to the easy interface and to some internal objects.

-- 
Bryan Henderson                                   San Jose, California