> IMHO Follow Daniel's advice and switch to the multi interface,

I beg to differ. As a user, I already found it simpler and cleaner
to write my own custom patch to the library, before even thinking of
submitting it.

> or live with the at most 1 second delay.

I probably would, but as you said there are other places than the
middle of the transfer where Curl_socket_ready() is called and blocks;
especially, when the connection is established, where the delay is not 1
second but 3 minutes: and in my use case, I can't afford that.

> You are trying to provide some functionality that tries to
> dramatically minimize the time required to react to an abort
> condition. If _many_ systems are not going to be able to benefit from
> it and it increases complexity then clearly it should not be adopted.
> [...] it would make no sense to provide a capability that only works
> sometimes and increases code complexity. No need for patch.

Again, I disagree. It makes sense to provide features only to platforms
and/or systems where it is supported, this is the point of configure
scripts.

But apart from providing new capabilities, why still not improving
existing ones? There is a whole difference between adding new options
and creating new code paths, and extending the existing abort mechanism
in a case where we already know anyway that a call was interrupted, but
blindly ignore it. It might not be a real, safe, warranted new feature,
but it would still be an _improvement_.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."