On Mon, 1 Feb 2010, Robert Iakobashvili wrote:

>> The downside of this fix, is that the counter we return in
>> 'running_handles' in several of our public functions then gets a slightly
>> new and possibly confusing behavior during times:
>
> curl-loader is using this number of "running handles" as the very particular
> indication to continue processing, as in line 116:
> http://curl-loader.svn.sourceforge.net/viewvc/curl-loader/trunk/curl-loader/loader_hyper.c?revision=566&view=markup

That should still work if I read things correctly. The returned counter will
still be actual "alive" handles that need care. The difference is just for
some cases the counter will never be incremented even though you add a handle,
as that handle fails so fast it never gets to bump the value and thus it won't
be decreased either.

Or how do you see my suggestion would alter the behavior of your code?

> If you chose this option to go forward, could the semantics of
> "running-handles" number include a sum of indeed running and failed to
> connect handles?

That would be a much bigger change. We'd need to special-case "failed to
connect" and also why would we count clearly failed transfers as a running
handle? It would make the value end up a positive number when all work is
done, and that's a rather big change imho.

> Sometimes failure to connect a socket is a rather transient event e.g. due
> to some pick load at server with a listen queue being full, or some
> temporary network issue, thus at a next cycle such socket may be
> successfully connected.

Yes a failed connect could work at next attempt, but libcurl itself doesn't do
the retry. It simply properly informs that the connect failed and the
application can then easily just re-add the handle again to get the connection
retried.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html