Re: Add CURLOPT_SERVER_RESPONSE_TIMEOUT_MS option

From: Timothe Litt <litt_at_acm.org>
Date: Mon, 20 Nov 2023 10:03:10 -0500

On 20-Nov-23 08:32, Cristian Rodríguez via curl-library wrote:
>
>
> On Sun, Nov 19, 2023 at 5:08 PM Ray Satiro via curl-library
> <curl-library_at_lists.haxx.se> 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.
>
>
> The granularity is up to the OS to provide, there is absolutely
> nothing you can do about it.
>
> My suggestion effectively stops proliferation of
> different TIMEOUT_WHATEVER options and provides exactly what
> application writers need, a parameter with the standardized type for
> intervals.
>
>
Not exactly.  As noted above, timespec_t only gives nsec; to truly
future-proof, one needs the structure type to be selectable

Further, the OS granularity doesn't always map directly to a curl
timeout.  A single curl call may invoke multiple operations, so
timekeeping errors can accumulate.  And multi (parallel) operations can
complete asynchronously, so the timeout on select/poll needs to be
what's left of the nearest deadline. These can require better
granularity from the OS than is specified to curl.

Ray's note hints at these complexities.

The best one can do is to specify a resolution that the (current) OS
understands - and expect that it's a lower bound that may be exceeded by
a considerable (and unknowable) margin.  The way to make the
specification future-proof and truly stop the proliferation of
TIMEOUT_WHATEVER options is to use a scheme with a variable type as
noted above.

Whether there are the use cases to support such an effort (vs. simply
adding one more _MS option) is a question for the proponents.  I do
believe that if yet another time resolution option is introduced, the
API should be future proof.


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

Received on 2023-11-20