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: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 19 Nov 2023 15:07:58 -0500
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.
Date: Sun, 19 Nov 2023 15:07:58 -0500
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.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-19