cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [patch] preliminary high_speed_limit patch

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 15 Jun 2006 23:39:59 +0200 (CEST)

On Wed, 14 Jun 2006, Peter wrote:

>> "separate calculations" ? You mean separate for read and write?
>
> I meant separate from speed calculations done in progress.c I'd like to see
> if I can get something to work leveraging progress.c rather than having
> similar information calculated independently as is done in the command-line
> implementation.

Oh, right. Yes it should be possible (in an easier way) when done within the
library.

> The other thing is... Curl_readwrite is scarily complex and long.

Yes it is. One of these days someone should break it down...

> I wanted to do a calculation outside of that routine, either before or
> after. trouble is, I don't know if I am reading or writing at that point.
> So How do I figure out which limit to apply?

Well, within Curl_readwrite() it gets to know if the socket is to be written
to or read from in the local 'select_res' variable. That info is not available
outside of that function unless you make it so. The k->keepon variable keeps
info on wheather the connection is still "active" for read and/or write.

>> 2 - when you calculate for how long the app can/should wait until it
>> calls curl_multi_perform() the next time it should set that time with
>> Curl_expire() since then nice upcoming apps that use curl_multi_timeout()
>> will work just perfectly with this concept too.
>
> will look... that's only in CVS... nicer to have a stable base to build
> patches from.

That function is available in 7.15.4!

> I saw that putting the throttle logic before calls to Curl_readwrite (in
> transfer.c and multi.c) would work, confirmed with initial (-Z patch) trial.
> If I look at both routines, neither differentiates between reading and
> writing. I do not see how to guess which direction a particular transfer is
> going in order to apply the correct limit. Ideas?

Since you base the logic on the values that already are calculated, I don't
see why you need to know in what direction(s) the transfer is currently going.
You can just see if the speed is above the limit in either direction and sleep
(or stay in the other state when we speak multi interface) for the (longest)
while to let the speed go below the margin again.

Or am I too naive?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2006-06-15