On 11/16/2014 5:57 AM, Daniel Stenberg wrote:
On Sat, 15 Nov 2014, Ray Satiro wrote:
Ok. To state the obvious the timeout behavior is different depending
on platform now. In the case of platforms other than Windows if there
are no fds select() will still sleep whatever is in timeout, which
could be less than the recommended minimum value of 100ms depending
on what is returned by curl_multi_timeout(). I assume that will
result in excess looping. But I tried to produce that just now in
Ubuntu 14 and couldn't since curl_multi_fdset is always returning fds
for me. Should the multi examples be changed for the other platforms
as well to sleep 100ms when there are no fds ready?
Yes, I think it makes sense to make them behave similarly so a 100ms
sleep would be good even for non-windows with maxfd is -1, if nothing
else to match what we're saying in the docs!
Ok I did that and submitted it via pull request last night. The changes
were pretty straightforward. Two more inconsistencies:
The multi examples other than multi-single don't follow the documented
cleanup order [1].
The multi examples multi_single and multi-debugcallback have a select
"badness" message and set still_running = 0 to exit the loop on select()
error but the others do not. I wonder the reason for that, because
assuming it is acceptable to continue looping after select error why not
call curl_multi_perform() again to update the number of running handles
as is done in the case of select() success. Then the loop will break if
there are no running handles (!still_running) or continue if there are.
But if select() error should be considered hard then why not set
still_running = 0 in all multi examples?
[1]: http://curl.haxx.se/libcurl/c/curl_multi_cleanup.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
