Poul-Henning Kamp wrote: > In message <4365EF7B.1020706_at_freebsd.org>, David Xu writes: >>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. > In thread program, we have to use clock_gettime, for example a thread wants to wait for condition variable for two seconds, it has to: struct timespec ts; clock_gettime(CLOCK_REALTIME, &ts); ts.tv_sec += 2; pthread_cond_wait(&cond, &mtx); problem is who really cares time precise? how many people are really handling realtime critical tasks? this is really an unpleasant side effect that a simple syscall can stall cpu. > >>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 > You can introduce other CLOCK_..., but auto tools won't detect them too, this means nobody will use them except us, probably worse then gethrtime. :-(Received on Mon Oct 31 2005 - 09:48:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC