On Sun, 3 Aug 2003, Daniel Noguerol wrote:

> Haha... okay, here's my solution... even if you don't want to use it, could
> you let me know if I'm doing something evil? ;)

Yes, this approach is evil!

Now, when the socket is readable and the select() call returns and you do not
read all the data that is available, you'll cause it to loop like crazy until
enough time has passed that will cause your code to make it read a little more
data.

Imagine the case where you accept only 1 byte per second, and when select()
returns there are 5 bytes available.

You'll then read 1 byte and return. The next select() call returns immediately
since there is still data available but you read nothing now and returns and
the select() returns at once... that makes close to 100% cpu usage.

To make this system work, you must explicitly prevent curl from doing the
select on that socket for the rest of the time when you are not fit to deal
with the data. When you've read 1 out of 5, you must make curl not select()
on that socket until a second later (or similar).

Also, what your system doesn't take into account (that the one in the
client-side curl code does) is: what if the transfer rate temporarily goes
below the max transfer rate. Should it really allow the transfer to go way
beyond the max transfer speed afterwards? In other words, your calculation for
max speed is based on the entire transfer, not just the "recent" period. I
think that defeats the purpose of using a max speed.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01