On Thu, 22 Aug 2013, yi huang wrote:

> Currently, my loop is a standard one, which is like this:
>
> while (1) {
> curl_multi_fdset(multi, &fdread, &rdwrite, &fdexcept, &maxfd);
> select(&maxfd, &fdread, &fdwrite, &fdexcept, timeout);

This is very naive and is not properly taking into account what
curl_multi_fdset() can return in the variables.

> Then i set timeout of select to 5 seconds(i don't want to wast too
> much cpu cycles),

That's not really optimal. Try using curl_multi_timeout() to get the best
timeout.

> i found that the process_response_body always delayed by 5 seconds.

I suspect you get this due to a minor flaw in libcurl in combination to how
your application uses the API. See below.

> I've investigated this by reading the source code of libcurl, i found out
> that after the last read of a http response, the easy_handle enter the
> CURLM_STATE_DONE state, and in next curl_multi_perform call, it enter
> CURLM_STATE_COMPLETED state, then the CURLMSG_DONE message got append to
> multi->msglist, then use code can detect the completion of a request. So i
> have to wait for another cycle to process my response body, and when io is
> not busy, this cycle can be very long.

Yes, I think you've found a legitimate problem!

I think the code in CURLM_STATE_DONE should set "result =
CURLM_CALL_MULTI_PERFORM" pretty much unconditionally so that it'll move on
and execute the next state immediately.

I've attached my suggested fix for this. Can you try it out and see if that
alone perhaps fixes your problem?

-- 
  / daniel.haxx.se

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