On Mon, 14 Apr 2008, Yang Tse wrote:

> It will also make the progress update function get called for _every_ single
> call to Curl_socket_ready() and Curl_poll() no matter what.

Ouch, I clearly didn't read it good enough! We can't have it do that.

> Before calling poll()/select() what actually has to be executed is a
> callback capable of returning a value which indicates if the operation
> should be aborted or not, but with no libcurl side effects. This could be
> done calling a Curl_checkAbort() function, before poll()/select() which
> would call, if defined, a user provided abort callback.
>
> I think that this sounds quite reasonable and nearly no overhead would
> be introduced.

Yes, if we really want to have it called that often and in those situations.

The subject of this thread and the description of this desired functionality
has though been to call the function "when poll()/select() is interrupted" and
since that should happen very rarely and just about once per transfer in a
typical application, I think calling the progress callback could work fine.

> In this way the 'classic' way of aborting libcurl would still be supported,
> and nearly no overhead would be introduced if the 'new' abort callback
> function is used or not.

Sure it would work fine, but I think the progress callback is fine for this as
long it isn't overused.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html