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 <anto...@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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
