curl-library
Re: running_handles and the multi API
Date: Mon, 1 Feb 2010 13:40:01 +0200
Hi Daniel,
On Sun, Jan 31, 2010 at 12:08 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> When curl_multi_socket_action() is called with no specific handle, but
> only
> a timeout-action,
>
Looks like our usage of the API for curl-loader was a bit different.
>
> A) The high performance fix is to introduce a loop in lib/multi.c (line
> 1988
> in current CVS), around the call to multi_runsingle() for the timeout-
> actions and simply check for CURLM_CALL_MULTI_PERFORM internally. This
> has the added benefit that this goes in line with my long-term wishes to
> get rid of the CURLM_CALL_MULTI_PERFORM all together from the public
> API.
>
> 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
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?
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.
Many thanks for libcurl and best wishes!
-- Truly, Robert Iakobashvili, Ph.D. ...................................................................... www.ghotit.com Assistive technology that understands you ......................................................................
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-02-01