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

[ykzhao]

On Tue, 2010-08-24 at 16:13 +0800, Daniel Stone wrote:
> On Tue, Aug 24, 2010 at 03:55:41PM +0800, ykzhao wrote:
> > On Tue, 2010-08-24 at 09:59 +0800, Daniel Stone wrote:
> > > That doesn't change anything - if a system is using ID 6 for something
> > > else, then using 6 is wholly incorrect, no matter whether you use the
> > > constant directly, define some other symbol for it, or whatever.
> > 
> > Maybe the system is using the ID 6 for something else. But in theory it
> > should not affect the system-call of posix timer.  
> 
> What do you mean, it shouldn't affect anything? What if timer ID 6 is
> being used for 'number of seconds since last email to xorg-devel'?

If we add a specific posix timer and the corresponding ID is 6, it can't
work. In such case we have no way to make it work. But this doesn't
happen on the upstream linux kernel. 

> 
> > If the CLOCK_MONOTONIC_COARSE posix timer is already supported in the
> > linux kernel(clockid is 6),  the system-call of "clock_getres/gettime(6,
> > &tp)" will return the valid value.
> 
> It will return a valid value _for that clock_.  That clock may be
> exactly what you don't want, if clock ID 6 is actually something else.
> 
> > If the CLOCK_MONOTONIC_COARSE is not supported in the linux kernel, the
> > system-call of "clock_getres/gettime(6, &tp)" will return the invalid
> > value, which indicates that we will fallback to the next posix
> > timer(CLOCK_MONOTONIC). 
> 
> Hopefully, yes.
> 
> > Of course there exists another scenario. The CLOCK_MONOTONIC_COARSE
> > posix timer is not supported. In course of compiling the Xorg we add the
> > macro definition of "CLOCK_MONOTONIC_COARSE=3".
> 
> 3?!?

It is only an example. What I want to say is that we will use the
incorrect posix timer if we explicitly add one definition of
"CLOCK_MONOTONIC_COARSE" for the following code:
   >clock_getres(CLOCK_MONOTONIC_COARSE, &tp)
  
   But in theory that won't happen on Linux. I agree with what Samuel
Thibault said. 

> 
> > In such case we will use
> > the incorrect posix timer after calling the function of
> > clock_getres(CLOCK_MONOTONIC_COARSE, &tp). But if we compile it again
> > under the latest glibc, we will get the warning message of "macro
> > redefinition". 
> > 
> > Based on the above consideration, not sure whether it is meaningful to
> > use the constant value(6) for the system-call of clock_getres? Otherwise
> > we will have to consider the following two cases:
> >     a. CLOCK_MONOTONIC_COARSE is not defined
> > in /usr/include/linux/time.h
> >     b. CLOCK_MONOTONIC_COARSE is already defined. But the corresponding
> > id is not 6.
> > 
> > If wrong, please correct me. 
> 
> 6 is not meaningful in any way.  Only CLOCK_MONOTONIC_COARSE, _as
> defined by the system headers_, means a coarse/non-HPET monotonic clock.
> Nothing else - not 6, not 3.  So, if it's not in the system headers, I
> don't think we should be using it.  I'm not really sure if I can be more
> clear ...

The CLOCK_MONOTONIC_COARSE is not defined in the header file for the
previous distribution. But it is really supported on the latest linux
kernel. If we define it, it is assured that it can work on both the
previous and latest kernel. Especially we compile it on the previous
distribution and execute it on the latest kernel.

What side effect will it bring if we define it explicitly and use it
when it is not defined in system header?