On Sat, 23 Jun 2007, Allen Pulsifer wrote:

> Just as a reminder, it does not address the issue of curl_multi_perform()
> needing to return CURLM_CALL_MULTI_PERFORM when it returns without reading
> the socket a second time.

Yes, and that's the part that'll involve most work or at least thoughts.

We've worked quite hard to make the multi socket API high performing so we
need to make sure we don't add anything (extra code or complexity I mean) to
that - currently the curl_multi_socket*() functions never returns
CURLM_CALL_MULTI_PERFORM so we would either have to introduce that or we would
have to take actions in the code to make sure it isn't needed for them.

Also, it struck me that moving the data_pending() to the before-check like
your patch, could potentially add a large number of extra recv() system calls
to the loop when we for example perform SSH-based uploads that don't receive
anything to download until the (huge) upload is done. The OpenSSL function may
of course also add some overhead but I don't think it involves a system call.
We would need to improve that function a bit to avoid that, but it should of
course be possible.

I can't but to think that if we'd make an effort to better support this,
wouldn't it make sense to make the flow-control more detailed? I mean perhaps
set a "receive window" that tells libcurl how much data you allow to be sent
to the callback and libcurl will not deliver any more until you set it again
to something > 0 ? Or is that just to overdo it?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html