[reSIProcate] Timers: why system time?

[Byron Campen]

	Ok, so this is in the "much more serious" category. I would not be  
comfortable leaving this be.

Best regards,
Byron Campen

> Byron Campen wrote:
>>    Let's say one of these timers is at the top of the heap, and  
>> whatever error you're thinking about happens. Are you saying that  
>> not only will that timer be 49 days late, but everything else in  
>> the heap will be too?
>
> Not new timers. But, if we miss the rollover, then everything in the  
> heap at that time will instantaneously appear to be 49.7 days later  
> than their original expiration time. New timers will be inserted in  
> the heap just fine (ahead of the "lost" timers), and expire correctly.
>
> The behavior would be similar to using our current stack and setting  
> the system time to be 49 days in the past while timers are pending.
>
> /a
>>
>>
>> Best regards,
>> Byron Campen
>>
>>> Technically, they won't be "lost" as much as "over 49 days late."  
>>> From a SIP protocol perspective, 49 days is long enough to  
>>> consider the timer lost for all practical purposes.
>>>
>>> /a
>>>
>>> Byron Campen wrote:
>>>>   I can see how we would miss a roll-over with low timer  
>>>> activity, but I am not sure what you mean by "lose timers". If we  
>>>> have lost a timer from a timer heap, that implies the heap is now  
>>>> broken, because that is the only way to "lose" anything. So this  
>>>> is either much more serious, or much less serious than you have  
>>>> stated.
>>>>
>>>> Best regards,
>>>> Byron Campen
>>>>
>>>>> 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 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
>>>>
>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2482 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20081031/eadc445a/attachment.bin>