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
Received on 2014-11-18