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