Hi, On Tue, Aug 24, 2010 at 11:05:23AM +0800, ykzhao wrote: > Maybe there is no definition of "CLOCK_MONOTONIC_COARSE" > in /usr/include/bits/time.h when compiling the xorg. But the xorg is > executed on the linux kernel that supports the CLOCK_MONOTONIC_COARSE > posix timer.(In fact for most previous Linux distribution there is no > definition of CLOCK_MONOTONIC_COARSE in /usr/include/bits/time.h). > If it is executed on the kernel that doesn't support the > CLOCK_MONOTONIC_COARSE timer, it will fallback to the CLOCK_MONOTOIC > posix timer(the function of clock_getres will return the invalid value). > > Do we need to consider the above scenario? If the above scenario doesn't > need to be cared, I will update the patch to assure that > the CLOCK_MONOTONIC_COARSE posix timer will be tried only when there > exists the corresponding definition.
Why not just fix glibc to include the definition? > > > If so, is there an approach that helps us to detect whether the > > > CLOCK_MONOTONIC_COARSE posix timer is supported on one OS? > > > > Try the following completely untested patch (hey, it compiles). It's > > not perfect though: if CLOCK_MONOTONIC or CLOCK_MONOTONIC_COARSE were > > ever 0, we'd make two or three syscalls for GetTimeInMillis() instead of > > one, and if either of them were ~0L, we'd never use them. > > the corresponding code is put under the condition definition of > MONOTONIC_CLOCK. This is already checked by using configure script. > > In theory the CLOCK_MONOTONIC exists if the MONOTONIC_CLOCK is > defined. Not sure whether it is still necessary to check the > CLOCK_MONOTONIC again? It was just an overly paranoid check to make sure that CLOCK_MONOTONIC actually works on the target system, as well as exists on the build system. I'm not sure if there's a Linux kernel we really support that doesn't have a working CLOCK_MONOTONIC, but I wasn't sure, so. I'd say CLOCK_MONOTONIC_COARSE -> CLOCK_MONOTONIC -> gettimeofday is the best order, given that it's in descending order of usefulness, but ascending order of likelihood of working. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
