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: Cristian Rodríguez via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 20 Nov 2023 10:32:41 -0300
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.
Date: Mon, 20 Nov 2023 10:32:41 -0300
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.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-20