cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PATCH] Call progress function when poll()/select() is interrupted

From: Yang Tse <yangsita_at_gmail.com>
Date: Wed, 16 Apr 2008 17:42:27 +0200

2008/4/16, Daniel Stenberg wrote:

> > typedef int (*curl_abortcheck_callback)(void);
>
> If you really need this kind of check before every select()/poll() call,
> isn't it just easier (and better) to just switch and use the multi interface
> ?

Good question. But I don't have a clear answer that fits all libcurl's users...

If the user feels comfortable using the multi interface, capable of
using fdsets, calling select() on its own, then I also think the user
should be using the multi interface to better achieve the near instant
abort capability.

On the other hand, the user might not want to call select() on its own
code, or might not know a word of what a socket is, or really
wants/expects libcurl to handle nearly everything for him, or desires
to have two versions of his app one using the easy interface and
another one using the multi one, or he really wants to stick to the
easy interface.

As a matter of fact I'm not saying _yet_ that the abortcheck callback
thing should be committed. I would rather see it finished and further
pros and cons discovered, discussed and addressed before a final
decision about its adoptability is taken.

For example, implications of calling the abortcheck callback from
Curl_pgrsUpdate()...

It sounds something reasonable and easy to do since libcurl code
already checks if Curl_pgrsUpdate() 'fails' and handles it with
CURLE_ABORTED_BY_CALLBACK. This is true for the easy and multi
interface with one exception: multi_runsingle() calls
Curl_pgrsUpdate() without checking its result only caring about the
updated average upload and download speeds.

This at least implies that the call to fabortcheck in
Curl_pgrsUpdate() should be done after it has done its calculations
and not at the beginning as i suggested in previous message.

-- 
-=[Yang]=-
Received on 2008-04-16