Yes, I want libcurl calls to be interruptible by a signal with less latency
than one second, at least most the time.
>First of all modify Curl_pgrsUpdate in such a way that it calls the
>_client_ app progress callback more frequently than once a second
>without breaking calculations. Taking in account that CPU usage should
>not skyrocket. This would be a single patch by itself.
>Second, add additional calls to Curl_pgrsUpdate if actually needed.
This will not affect the most important case -- where the transaction
is stuck because the server is not sending anything. Unless we can
get Curl_select() to return so that Curl_pgrsUpdate can be called,
it's not even worth writing code.
>And as a last resort reduce from 1000 ms the timeout in select() and
>poll() calls to just 500 ms. Nobody wants busy loops eating CPU.
Based on what I said above, this is actually the starting point. But
it's not enough either. If we're going to go with an arbitrary fixed
time polling, I think the existing 1000 ms is as good an interval as
Except in some real time control systems, interrupt based response to
outside events is practically always superior to polling for them.
>Your general idea is fine, but that
>patch implementation is a real problem for what I, and others have
The only thing I've heard about the implementation so far is the
problem with updating the counters in Curl_pgrsUpdate more than once a
second. I have held off on commenting on that because it's separable
from the issue of getting Curl_select() to return so that the progress
callback can be called; so I wanted to cover any problems with that
But also because I don't understand the Curl_pgrsUpdate code as well;
I originally had code that did _not_ update the counters more than
once a second because it looked like that might be important, but I
couldn't really tell. I asked, and Daniel said the reason for the
once-a-second limitation was just to keep the built-in progress meter
from running more than that. Given that, I changed to what you see
now. From your analysis, it looks like my first impression might have
been better. But I don't want to keep flailing at that code if Daniel
has a different vision for it.
Bryan Henderson San Jose, California
Received on 2007-03-13