>
> 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.
>

Perfect...

I have a second patch coming... you can ignore the sleep patch, because
I don't need it anymore. I am preparing a new patch which checks either
direction and, in either multi or easy case, no longer makes the fd included
in the set monitored by select. It is based on the fact that all the select
calls have 1 second timeouts.

        -- if it is too fast (read or write, checking both) (in multi-state,
CURLM_STATE_TOOFAST, in single it just checks the speed in fdset directly.)
then do not put the fdset in the list

        -- while it is too fast, when select returns (at least every second), do a
pgrsUpdate. if the speed is ok, then add the fd back (CURLM_STATE_PERFORM or
 fdset in single case just checks the speed.)

That's it.

so the computational cost is an pgrsUpdate once a second, and an if statement.
There is no sleep needed.
Received on 2006-06-16