Re: Select returns -1 on all the multi examples in win32
Date: Wed, 19 Nov 2014 13:45:46 +0100 (CET)
On Mon, 17 Nov 2014, Ray Satiro wrote:
> Ok I did that and submitted it via pull request last night. The changes were
> pretty straightforward.
Thanks a lot, I just merged that one.
> The multi examples other than multi-single don't follow the documented
> cleanup order .
It would of course be nice to get them to use the proper order as well. The
order is more a SHOULD than MUST though and libcurl really should handle
basically whatever order the app uses.
> 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,
Probably mostly because they're written at different times, from different
templates/sources and possibly even by different people.
> assuming it is acceptable to continue looping after select error
But is it? I think that's the question and I really can't give a good answer
to it. If it fails on select() once, why would calling curl_multi_fdset again
give anything different and given the same input surely a second invoke of
select() will fail the same way again?
> 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.
I think because if select() continues to return -1, it'll effectively become a
busyloop eating 100% CPU.
> But if select() error should be considered hard then why not set
> still_running = 0 in all multi examples?
Leaning back and forth on this matter, I think I now favor treating it as a
hard error. I can't think of any legitimate reason why it would be allowed to
return -1 and have things continue.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2014-11-19