[Click] Strange timer behavior

[Eddie Kohler]

Roberto,

Remember that initialize() is called exactly once.  If initialize() is called 
before the system time adjustment then it will take a long time for _next to 
catch up!

I don't see what's so hard to understand about this.  If you just want to run 
the timer every 10000ms use _timer.schedule_after_msec(10000).

Eddie


Roberto Riggio wrote:
> Eddie,
> 
> ok in order to simply the problem I've increased the confusion. This is the
> run_timer method:
> 
> void
> Blank::run_timer(Timer *)
> {
>   click_chatter("Pruning...")
>   _next += Timestamp::make_msec(10000);
>   _timer.schedule_at(_next);
> }
> 
> _next is set to Timestap::now() in the element's initialize method.
> 
> R.
> 
> ----- "Eddie Kohler" <kohler at cs.ucla.edu> wrote:
>> Roberto,
>>
>> What is "now"?  Not Timestamp::now().  It must be some variable that
>> you are 
>> maintaining.
>>
>> If you want the timer to run once, use
>>
>> schedule_at(Timestamp::now() + delay)
>>
>> or equivalently
>>
>> schedule_after(delay)
>>
>> If you want the timer to run 60 times, use
>>
>> now = _timer.expiry();
>> ...
>> schedule_at(now + delay)
>>
>> or
>>
>> reschedule_after(delay)
>>
>> Eddie
>>
>>
>> Roberto Riggio wrote:
>>> Eddie,
>>>
>>> I don't know if it is really a problem. I use schedule_at
>>> in order to schedule the timer at X. Then, in run_timer I do 
>>> something like this:
>>>
>>> schedule_at(now + delay)
>>>
>>> now let's assume that I change the system clock while click is
>>> running moving it forward one hour.
>>>
>>> Then if delay is 1 min run_timer is executed 
>>> 60 times right after the clock change is committed.
>>>
>>> Is this the expected behavior?
>>>
>>>
>>> ----- "Eddie Kohler" <kohler at cs.ucla.edu> wrote:
>>>> Roberto,
>>>>
>>>> I don't know exactly what the "problem" is here, which behavior do
>> you
>>>> not like?
>>>>
>>>> The meaning of "schedule_after" is "schedule at X past the current
>>>> time."  The 
>>>> meaning of "scheudle_at" is "schedule at the moment the system
>> clock
>>>> says X." 
>>>>   These methods are behaving correctly.
>>>>
>>>> Eddie
>>>>
>>>>
>>>> Roberto Riggio wrote:
>>>>> Hi,
>>>>>
>>>>> the problem is the following: if I use the schedule_at function
>>>>> in order to reschedule a timer I get the timer scheduled several
>>>>> times if i move the system clock forward.
>>>>>
>>>>> On the other hand if I use the schedule_after function this
>>>>> does not occur and the timer is scheduled only one even if I move
>>>>> the clock several years in the future.
>>>>>
>>>>> The problem is annoying because I'm using click over an embedded 
>>>>> platform that forget the system date at each reboot (the default
>>>> date
>>>>> is Jan 2000).
>>>>>
>>>
> 
>