On Thu, 10 Aug 2017, Jack wrote:

Unconditionally returning every 10 milliseconds like this will make you
spend a lot of CPU in vein. Don't do that.

[Fan] Maybe this is not root cause, because when no http request send, CPU almost 0.1%.

Sure, but doing like that unconditionally is usually a sign of not having understood the libcurl event API correctly.

I think you should put the curl_multi_info_read() call outside of the loop
checking for activities

[Fan] So, when do I call curl_multi_info_read?

First, curl_multi_info_read() is super fast to call so its not like this is going to cause you a lot of wasted CPU. I just think it felt wrong to do it that often. You can of course decide yourself when to call it.

You call curl_multi_info_read() to figure out what transfers that have completed, right?

I would first handle all the events that need taking care of, *then* I would loop over curl_multi_info_read() to see which transfers that ended. Comparing with the hyperfifo example isn't really fair since that's using libevent which delivers each event one by one to a callback so it can't easily wait with the call to curl_multi_info_read().

CURLMOPT_TIMERFUNCTION not about epoll fd, is it right? CURLMOPT_TIMERFUNCTION only indicating whether time out or not.

CURLMOPT_TIMERFUNCTION gives you the longest time from that moment until you should call socket_action() with the TIMEOUT argument. If another event triggers before that timer has lapsed, chances are you'll get an updated timeout so that many timeouts never trigger but are simply moved further away in time.


 / daniel.haxx.se
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Reply via email to