On 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.
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
