[Click] Strange timer behavior

[Eddie Kohler]

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).
>>>
> 
>