Daniel Stenberg wrote:
Just use it as documented and that's how it'll work.
Documentation suggestions aside, I think I understand the multi API now
but would like to check my logic on a design which makes sense to me but
is not shown in any docs or example code.
Before using multi API my code looked like this:
while (select(input_sockets)) {
[process input data]
[configure easy handle to upload results]
curl_easy_perform()
}
Since curl_easy_perform is synchronous, naturally all input processing
halted until the upload was done. That's the problem I need to fix, and
it seems to me it can be done by simply changing to:
while (select(input_sockets)) {
[process input data]
[configure easy handle to upload results]
[add easy handle to multi stack]
while (CURLM_CALL_MULTI_PERFORM != curl_multi_perform(...))
}
while (CURLM_CALL_MULTI_PERFORM != curl_multi_perform(...))
Note that there is no direct use of select() to "protect" the call to
curl_multi_perform; select is still used only on input sockets. The doc
says "Your application can acquire knowledge from libcurl [using
curl_multi_fdset] when it would like to get invoked to transfer data, so
that you don't have to busy-loop and call that curl_multi_perform(3)
like crazy"; however, this code won't busy-loop anyway because it'll go
right back into the select loop on *input* data. Thus, every time it's
done processing all available input, it'll take a moment to send as much
output as possible without blocking and then go back to handling input,
which is the priority. The final while loop is just there to sweep up
any leftover data.
Is there anything wrong with this? Yes, I could use curl_multi_fdset and
add the result to the set of descriptors monitored by select but I can't
see much value added; seems to me it could at best avoid an occasional
unnecessary call to curl_multi_perform but it seems that's pretty cheap
when there's nothing to do anyway ...
Thanks,
MB
