M. Warner Losh wrote: >: thread libraries use clock_gettime, this becauses there is >: pthread_cond_timedwait and other synchronization objects >: like rwlock, and mutex all have a timeout version, I think >: pthread_cond_timedwait is mostly used in some applications, >: though normally, application is not looking for high accuracy. >: they will get benefit from the clock_gettime speed improvement. > >And unfortuantely, the argument that needs to be passed to abstime is >unspecified, at leas tin our man page. Also unfortuantely, >CLOCK_REALTIME seems to be what's required here (our man page just >says 'if the system time reaches the time specified in abstime'), >rather than CLOCK_MONOTONIC so jumps in system time can cause >previously short timeouts to become rather large timeouts... This is >a flaw in the API. :-( > >Warner > > I would rather to think it is brokeness of POSIX thread API specification, in real world, nobody uses the timeout as an absolute timestamp, almost all applications are doing relative timeout sleep, if implementor 100% respects POSIX spec, he will break many applications. libthr supports pthread_condattr_setclock, you can select CLOCK_MONOTONIC for pthread_cond_timedwait, but internally, all absolute timeout waits are converted to relative. David XuReceived on Sat Oct 29 2005 - 03:01:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC