On Mon, 7 Oct 2013, Kamil Dudka wrote:
... if there is nothing to wait for. This fixes a regression introduced by
commit 0feeab78 limiting the speed of SCP upload to 16384 B/s on a fast
connection (such as localhost).
Thanks for the patch. I'm just a little concerned that this fix corrects the
symptom rather than actually addresses the underlying problem.
Let me explain what I suspect and once given some research we can decide on
how to act on it.
The change 0feeab78 you mention was a change that would prevent libcurl from
busy-looping like crazy when it found nothing to wait on. (That code was later
adjusted by d529f3882b.)
The key here is the "nothing to wait on" part. When there's a transfer going
on, even SCP, there should be a file descriptor to wait for[*] and the
previously mentioned logic should not kick in. If that logic works, I don't
think this patch is necessary.
Since your patch clearly helps your case (as otherwise you wouldn't have
posted it) I can only deduct that curl_multi_wait() in this case returns a
zero in its fifth argument to signal that there's no file descriptor to wait
for, and yet there should be as there's a transfer in progress!
Did I understand this correctly?
If so, we need to dig further why libcurl wrongly drops the file descriptor,
right?
[*] = it will also return faster when there's a timeout that has expired but
that shouldn't happen in multiple fast invokes so I don't think that's what
you see happening.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
