Patch looks good. I¹m now using the latest code and haven¹t come across any
busy loops as of late. As long as syscalls aren¹t sub microsecond I think
we¹ve fixed this for now. Will ping the mailing list if I do.

If we have to fix it otherwise, I was thinking of breaking out of the
timeout loop in multi_socket if we every try to call multi_runsingle on the
same easy handle twice in a row. Or maybe bounding that loop to say 100
iterations or something. In general in event loops you want to have bounded
execution so we don¹t starve other parts of the program (say non curl
connections).

One side effect of this code is that now when a new connection is added (or
a number of other events), the connection is delayed 10 milliseconds before
it actually starts by the last couple lines of multi_runsingle(). Before as
long as we didn¹t cross a second boundary they code would run immediately.

Thanks,
Chris

          
  if(CURLM_CALL_MULTI_PERFORM == result)
    /* Set the timeout for this handle to expire really soon so that it will
       be taken care of even when this handle is added in the midst of
       operation when only the curl_multi_socket() API is used. During that
       flow, only sockets that time-out or have actions will be dealt
       with. Since this handle has no action yet, we make sure it times out
to
       get things to happen. Also, this makes it less important for callers
of
       the curl_multi_* functions to bother about the
CURLM_CALL_MULTI_PERFORM
       return code, as long as they deal with the timeouts properly. */
    Curl_expire(easy->easy_handle, 10);

On 5/7/08 8:57 AM, "Yang Tse" <yangsita_at_gmail.com> wrote:

> Hi all,
>
> I reply to myself just because its the last message in the thread :-)
>
> I have just committed to CVS Christopher Palow's microsecond
> resolution keys for internal splay trees patch with some editing done
> by me to avoid changing libcurl's external API.
>
> Christopher, if you're still around, could you test if this actually
> minimizes the original busy waiting problem for you ?
>
> Could you do something complimentary to actually address the busy
> waiting if this is still needed ?
>
> --
> -=[Yang]=-
>
Received on 2008-05-12