Re: [reSIProcate] Timers: why system time?
Scott (and any other Windows developers on the list):
The Windows 49.7-day rollover fix in this patch uses heuristics to
handle the rollover in an efficient manner -- you can actually lose
timers if you have relatively low timer activity and a multi-minute
timer running when the tick count rolls over. The chances of this
happening are, admittedly, vanishingly small (especially in normal SIP
usage). In any case, you might want to give that code a quick review to
ensure that you're comfortable with it.
Also, I think it's safe to say that it's difficult to test the
correctness of the code, as step one of any such test plan necessarily
involves something like: "boot a Windows machine and wait 49.6 days."
Make sure you're comfortable with that fact as well.
/a
Alexander wrote:
Hi
Here is a patch to use monotonic clock.
It is 3 modified files from reSIProcate 1.4.
Attached files have Windows (CLRF) eof-style.
Windows
=======
GetTickCount() with 16 ms inaccuracy used.
It is very simple to change it to timeGetTime() etc with 1 ms accuracy,
but it will require init/fini calls on application level and linking
with Winmm.lib
Tested on Windows XP SP2, compiled with VS7.1
Not tested on Windows CE
Linux
=====
If monotonic clock is not available (compile time and runtime) it will
fall back to gettimeofday()
I am not familiar with reSIProcate build system so I use workaround to
avoid linking with librt:
syscall( __NR_clock_gettime, ... )
instead of clock_gettime(...)
IMHO it may not work on other POSIX compliant platforms.
Pass only some basic tests on my Linux PC (2.6.18 kernel)
Any feedbacks appreciated.
Regards
Alexander Altshuler
Xeepe team
http://xeepe.com
------------------------------------------------------------------------
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel