Daniel Stenberg wrote:
> Even I have used that change in handle counter to signal "end of a
> transfer". The only *good* way to find the end of a individual
> transfer
> is calling curl_multi_info_read() to see if it returns one.

<snip, snip>

> Further, curl_multi_info_read() is not as "cheap" as we'd like it
> to be
> for being this single function to use for this purpose. It
> currently scans
> over all added easy handles and we should improve that to instead
> become
> a proper queue of messages that is instant to check if empty.

<snip again>

> Hm, now when I've spent the time to write all this, I must say I lean
> towards method (A) rather strongly even though it may alter behavior
> slightly.
>
> If you've read this far and have an idea of what I've tried to say,
> I'd say you're qualified to have an opinion on the matter so please
> tell me what you think or if I've missed some detail or whatever.

I think I understand, and without being very knowledgeable about all the
details my gut reaction is that method A sounds like a solution that is
a lot more solid.

Your comment that "even you have used that change in handle counter..."
is not a very good argument in favor of method B, and you even say so
implicitly when you also state that "the only good way to find the end
of an individual transfer is calling curl_multi_info_read()"

The running_handles counter is simple to use, yes, but relying on it to
tell you state changes does seem like over-using the feature. And don't
get me wrong, I'm the laziest programmer alive and I'm pretty sure my
code will always look worse than yours. Give me an API that allows me to
make shortcuts and I will! That's why I think it's a bad idea to allow
even the possibility. If running_handles is not a good way to detect
state changes, and maybe even not 100% accurate at telling the current
state of things, then I would degrade it to an "informational" feature
without guarantees, and document it as such. If the official stance (and
the docs) say that this feature should not be used for anything serious,
then even I would probably avoid that kind of behaviour.

It seems a lot better to do that, and spend some time on optimizing
curl_multi_info_read() than try and keep what might be an
over-simplified indicator of state (and state changes) and claim it is
fully accurate. It sounds as if that claim will be a lot more difficult
to live up to.

cheers,

  /Ragnar

-- 
______________________________
Load Impact
Ragnar Lönn
Email: ragnar.lonn_at_loadimpact.com
Web: http://loadimpact.com
How many users can your website handle? - Test at: http://loadimpact.com
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html