In message <4365EF7B.1020706_at_freebsd.org>, David Xu writes: >Robert Watson wrote: >> >> >> It has been suggested that the former can operate quite well with >> significantly reduced quality. It has alos been suggested that most >> applications could operate fine with somewhat reduced quality, but that >> the API definitions don't say anything about how to specify application >> quality requirements vs performance requirements for time measurement. > >Can we change gettimeofday and clock_gettime to lower resolution now? I can live with gettimeofday(2) and time(3) being degraded. I am going to insist that clock_gettime(CLOCK_REALTIME, CLOCK_UPTIME) remain precise. >I think 1000hz/s is enough for most applications, since a thread can >never sleep shorter than a tick for years. (Famous last words!) Time is not just a matter of sleeping. >We can introduce >hrtime_t clock_gethrtime(clockid_t clock) to get hi-resolution time >as the one seen in RTLinux, or gethrtime() as seen in Solaris (Daniel >Eischen said?) You know ? This is just a great example of why people feel the autocrap tools is the way to write portable code :-( The open group specifically allow clock_gettime() to implement more timescales, so what did those fools go and invent even more library functions for ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk_at_FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.Received on Mon Oct 31 2005 - 09:26:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC