Re: [reSIProcate] Timers: why system time?
I agree as well. It's too bad that a there isn't a decent solution that's
non-heuristic. I would hate to see this become an issue down the road with
the global lock causing some kind of hiccup (yes, also chances seems
ridiculously small) or some unforeseen usage problem.
Alternatives might be: Update the ticker in a single stack thread, assigning
a stack responsibility to update the ticker at a reasonable interval. It
would remove the global lock and need for heuristic approach, but assigning
a stack seems like it wouldn't be straightforward. Another, less supported
approach would be to use a 64-bit CompareAndSwap in getTimeMs(), but the
64-bit CAS may have platform support issues (windows CE, unsupported CPU's -
although they are all most likely not in use, etc..).
-justin
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Scott Godin
Sent: Thursday, October 30, 2008 12:19 PM
To: Alexander Altshuler; resiprocate-devel
Subject: Re: [reSIProcate] Timers: why system time?
Yes, I agree - it will be called reasonably often enough for this to be
a non-issue. And it's noted well in the comments for other external
uses to beware.
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of
Alexander Altshuler
Sent: Thursday, October 30, 2008 12:04 PM
To: 'resiprocate-devel'
Subject: Re: [reSIProcate] Timers: why system time?
Hi All
Timer::getTimeMs() is called from BaseTimerQueue::msTillNextTimer()
So IMHO it will be often called independent from existing timers.
Regards
Alexander Altshuler
Xeepe team
-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: Thursday, October 30, 2008 6:27 PM
To: Alexander
Cc: 'resiprocate-devel'
Subject: 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.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel