[reSIProcate] Timers: why system time?

[Justin Matthews]

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 at resiprocate.org
[mailto:resiprocate-devel-bounces at resiprocate.org] 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 at resiprocate.org
[mailto:resiprocate-devel-bounces at resiprocate.org] 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 at nostrum.com] 
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 at resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel