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 [1].
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.
Can you? -- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
