[PATCH] use CLOCK_MONOTONIC_COARSE posix timer instead of CLOCK_MONOTONIC in Xorg

[ykzhao]

On Tue, 2010-08-24 at 12:46 +0800, Daniel Stone wrote:
> 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.

I also agree that it is very pretty to get the time by using mentioned
order. But the configure script already helps us to test whether the
MONOTONIC_CLOCK is supported(It uses the CLOCK_MONOTONIC as the argument
of clock_gettime). 
   If so, maybe we can avoid some redundant check. 

Thanks.


> 
> Cheers,
> Daniel