On 20-Nov-23 08:32, Cristian Rodríguez via curl-library wrote:
Not exactly. As noted above, timespec_t only gives nsec; to truly future-proof, one needs the structure type to be selectableOn Sun, Nov 19, 2023 at 5:08 PM Ray Satiro via curl-library <curl-library@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.
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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
