Herold Heiko <[EMAIL PROTECTED]> writes: > Ok, fine. But, in order to avoid misunderstanding, wouldn't it be > better to have a wrapper function (msleep ?) and use that where > really millisecond granularity is desired ? Otherwise sooner or > later somebody could use usleep where really microsecond granularity > is desired,
IMO anyone who calls usleep() and expects perfect microsecond granularity deserves what he gets. Wget is certainly not, so using usleep is fine. I agre that "msleep" would make more sense with how Wget is using it, but usleep() was already there, so I used that. There's also a "nanosleep", but I really hate filling out a structure just to sleep. The other thing is, I really dislike having application-specific wrappers for *all* OS functionality. I know most big applications take that route, but it doesn't mean it's necessarily a good thing. > What I mean is, while testing that I found (like expected) with a ~ > 30kb/sec connection to the server and a --limit-rate=100 wget would read > a whole buffer, sleep for several seconds, read another full buffer and > so on Yes; that's supposed to happen. I don't think we can do much about it in a portable fashion. Besides, is it ever useful to limit the bandwidth to 100 bytes/s? Even people with 56kbps modems limit to 2 or 3 k. > Wasn't there some time ago a bandwidth patch floating around which > played with window sizes instead of pausing ? I don't think so. There was a time when I examined the bandwidth-limiting patches, and I couldn't find any that did that. They were just sleeping, and most of them incorrectly.
