[Lazarus] Better implementation of GetTickcount using clock_gettime

[Michael Van Canneyt]

On Wed, 2 Apr 2014, zeljko wrote:

> On 04/02/2014 01:10 PM, Mattias Gaertner wrote:
>> On Wed, 02 Apr 2014 13:45:08 +0300
>> Anton Kavalenka <anton.k at tut.by> wrote:
>> 
>>> [...]
>>> Yes - CLOCK_MONOTONICC_RAW is prefreable, because general GetTickCount()
>>> is number of millisecond ticks since system startup. It cannot be
>>> adjusted by time services, it just grows up every 1 msec.
>>> Ant typical GetTickCount() usage - find a difference between subsequent
>>> values.
>>> It would be amazing when difference gets negative.
>> 
>> The NTP changes in CLOCK_MONOTONIC only accelerates or slows it down. It
>> tries to fix the ticks for e.g. busy systems or VMs. It is still
>> monotonic.
>> 
>> CLOCK_MONOTONIC_RAW would better emulate the WinAPI
>> function GetTickCount.
>> I guess most programs need CLOCK_MONOTONIC.
>
> My guess is that there no need to speculate what most programs need but what 
> is more precise or better to say what is correct.
> IMO CLOCK_MONOTONIC is affected by eg. ntp/adjtime() so result of 
> GetTickCount() is not correct in all cases.
> Imagine daemon service which relies on GetTickCount and then clock change due 
> to the daylight via ntp (eg. ATicks := GetTickCount , and after function "if 
> GetTickCount - ATicks > XXXXX THEN 
> sendalarm_email_to_admin_because_this_job_takes_too_much_time".
> Maybe I'm wrong, but we should set CLOCK_MONOTONIC_RAW instead of 
> CLOCK_MONOTONIC for linux targets if kernel version matches minimum for 
> CLOCK_MONOTONIC_RAW (same thing should be done in fpc - Michael already 
> commited CLOCK_MONOTONIC afair).

Looking at the documentation of GetTickCount(64), I'd say that the _RAW function is the better one.
So we can do a get with CLOCK_MONOTONIC_RAW, if it returns EINVAL we retry with CLOCK_MONOTONIC.
And if that fails, we fall back to gettimeofday.

I see no reason why it cannot be changed like this. Main point is that it is transparant to the user.

Michae