Hi Daniel, On Sun, Jan 31, 2010 at 12:08 AM, Daniel Stenberg <[email protected]> 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
