Re: [reSIProcate] Timers: why system time?
- From: "Alexander" <alt@xxxxxxxxx>
- Date: Wed, 22 Oct 2008 19:44:17 +0400
Hi Valentin
All reSIProcate timers are relative in essence.
I have problems with my reSIProcate based application running on desktop
PC when user changes system time.
It is not often, but occasional use case.
Yes, it very simple to detect CLOCK_MONOTONIC availability on compile
time, so my offer is to use monotonic time for all relative timers if
possible
If application needs real wall-time timer like from your example it must
use different tool instead of existing postMS().
Regards
Alexander Altshuler
-----Original Message-----
From: Valentin Nechayev [mailto:netch@xxxxxxxxxxxx]
Sent: Wednesday, October 22, 2008 6:30 PM
To: Alexander
Cc: 'resiprocate-devel'
Subject: Re: [reSIProcate] Timers: why system time?
>>>>> Alexander <alt@xxxxxxxxx> wrote:
> reSIProcate timer framework uses system time.
> If one will change system time on PC it will damage timers processing.
Unfortunately, there is no timer API in Unix systems which works
for all systems and provide monotonic clock. clock_gettime() with
CLOCK_MONOTONIC is marked as separate option in Posix. times()
(return value) is known to show incorrect time on many systems. Of
course, it is possible to use monotonic time if available
(detected at compilation time) and wall time otherwise, but really
the problem is more complicated - which timer should be really
treated as relative and which one as absolute? If application
calculates "this call attempt shall be cancelled at 18:00 because
work time is over and nobody will hook off on reception table",
this shall be absolute timer even if generated from "Expires:
250".
So it's better to do now using one known stable measure (wall
time) and switch to mix it with local monotonic clock only when
applicable and where applicable. (I.e. wait for next OS which will
reflect this correctly.;))
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@xxxxxxxxxxxx
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.2/1738 - Release Date:
21.10.2008 14:10