I'm very happy with curl :) but the way I implemented http code in our project is by using 1ms busy wait worker thread that doesn't even use curl_multi_wait. It simply sleeps(1ms) and then does curl_multi_perform. One of the reasons is because I wasn't able to (or rather didn't want to) implement portable code that would be able to "unblock" curl_multi_wait call if I needed to. On non-windows systems generally it's a simple task: an anonymous pipe can be used to alert curl_multi_wait. On windows however, this won't work as select on windows requires socket to be passed. It would be helpful if libcurl instead provided through some api a way to unblock curl_multi_wait call from another thread (perhaps internally it already has something like that?).
On non-windows systems it may implement it as anonymous pipe. On windows it may use self-connected udp socket (this way nobody on localhost would be able to send data to it).
I'm very happy with curl :) but the way I implemented http code in our project is by using 1ms busy wait worker thread that doesn't even use
curl_multi_wait. It simply sleeps(1ms) and then does curl_multi_perform. One of the reasons is because I wasn't able to (or rather didn't want to) implement portable code that would be able to "unblock" curl_multi_wait call if I needed to. On non-windows systems generally it's a simple task: an anonymous pipe can be used to alert curl_multi_wait. On windows however, this won't work as select on windows requires socket to be passed. It would be helpful if libcurl instead provided through some api a way to unblock curl_multi_wait call from another thread (perhaps internally it already has something like that?).On non-windows systems it may implement it as anonymous pipe. On windows it may use self-connected udp socket (this way nobody on localhost would be able to send data to it).