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