Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Add CURLOPT_SERVER_RESPONSE_TIMEOUT_MS option
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Sun, 19 Nov 2023 15:31:55 -0500
On 19-Nov-23 15:07, Ray Satiro via curl-library wrote:
> On 11/19/2023 2:35 PM, Timothe Litt via curl-library wrote:
>>
>> While I agree that a struct timespec* would be a better choice,
>> consistency in an API is important.
>>
>> All the other _MS functions could also use a stuct timespec (you get
>> nanoseconds).
>>
>> Perhaps a (CURLOPT_PRECISE_TIMEOUT, {CURLOPT_SERVER_RESPONSE_TIMEOUT,
>> ...}, struct timespec*)?
>>
>> This would reduce the CURLOPT namespace intrusion...
>>
>> One could also include an enum to specify that the reference is to a
>> timespec (vs. some future picosecond structure, or even integer
>> seconds, usec (struct timeval *), jiffies - or whatever else the
>> future brings.)
>>
>
> Nanosecond timeouts are not useful for curl because there is too much
> out of our control to support that level of granularity. It is hard
> enough with milliseconds. If you have a timeout 100ms then curl might
> not be able to stop until 120ms or even some longer time depending on
> scheduling, how often the timing is checked and how long other
> functions take to execute, some of them outside of curl's control.
> curl makes a best effort.
>
I agree that timeouts can be hard; they always have been. On the other
hand, when the OS provides a resolution, passing it on can't hurt.
Every OS already specifies that scheduling, clock resolution, IO, lock
contention, etc mean that the requested timeout/delay is imprecise and
effectively a lower bound.
However, the main points are that IF you provide a more precise (not
necessarily accurate) option, the API should be consistent and
preferably extensible. Implementing a more precise (e.g. timespec_t *)
option for just one timeout would be a mistake.
I can remember when microsecond time values seemed silly (you measured
cycle times in 10s of usec or more; instructions taking 10s of cycles) -
then nanoseconds were silly (early implementations used quanta of 100
ns). So Dennard scaling limits notwithstanding, someday ms will seem
trivial, usec easy, .... and psec the wave of the future. Extensions
happen; curl can wait or anticipate. As for I/O: 19.2K RS232 was hard;
today's 400Gb/s ethernet was unthinkble (much less 1.6Tb/sec). So I
wouldn't lock-in the time-representing structure of the month....
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2023-11-19
Date: Sun, 19 Nov 2023 15:31:55 -0500
On 19-Nov-23 15:07, Ray Satiro via curl-library wrote:
> On 11/19/2023 2:35 PM, Timothe Litt via curl-library wrote:
>>
>> While I agree that a struct timespec* would be a better choice,
>> consistency in an API is important.
>>
>> All the other _MS functions could also use a stuct timespec (you get
>> nanoseconds).
>>
>> Perhaps a (CURLOPT_PRECISE_TIMEOUT, {CURLOPT_SERVER_RESPONSE_TIMEOUT,
>> ...}, struct timespec*)?
>>
>> This would reduce the CURLOPT namespace intrusion...
>>
>> One could also include an enum to specify that the reference is to a
>> timespec (vs. some future picosecond structure, or even integer
>> seconds, usec (struct timeval *), jiffies - or whatever else the
>> future brings.)
>>
>
> Nanosecond timeouts are not useful for curl because there is too much
> out of our control to support that level of granularity. It is hard
> enough with milliseconds. If you have a timeout 100ms then curl might
> not be able to stop until 120ms or even some longer time depending on
> scheduling, how often the timing is checked and how long other
> functions take to execute, some of them outside of curl's control.
> curl makes a best effort.
>
I agree that timeouts can be hard; they always have been. On the other
hand, when the OS provides a resolution, passing it on can't hurt.
Every OS already specifies that scheduling, clock resolution, IO, lock
contention, etc mean that the requested timeout/delay is imprecise and
effectively a lower bound.
However, the main points are that IF you provide a more precise (not
necessarily accurate) option, the API should be consistent and
preferably extensible. Implementing a more precise (e.g. timespec_t *)
option for just one timeout would be a mistake.
I can remember when microsecond time values seemed silly (you measured
cycle times in 10s of usec or more; instructions taking 10s of cycles) -
then nanoseconds were silly (early implementations used quanta of 100
ns). So Dennard scaling limits notwithstanding, someday ms will seem
trivial, usec easy, .... and psec the wave of the future. Extensions
happen; curl can wait or anticipate. As for I/O: 19.2K RS232 was hard;
today's 400Gb/s ethernet was unthinkble (much less 1.6Tb/sec). So I
wouldn't lock-in the time-representing structure of the month....
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature