Opened 2 years ago

Last modified 2 years ago

#4066 new defect

IntervalTimer interval vs due - now

Reported by: fdupont Owned by:
Priority: low Milestone: Outstanding Tasks
Component: Unclassified Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

IntervalTimer? provides only the interval, i.e., the delay between setup and callback call, when some code (perhaps soon obsoleted) need the delay to the callback call (i.e., due - now).

Subtickets

Change History (7)

comment:1 Changed 2 years ago by fdupont

The canonical example is receive[46] in DHCPv[46] servers.

comment:2 follow-up: Changed 2 years ago by tmark

There are currently two modes, ONESHOT and REPEATING. You seem to be talking about when a timer is in REPEATING mode. I believe that this functions as designed. The intent is for the timer expire at fixed intervals, not intervals relative to what happens after the timer expires. In other words, once started, and unless modified it should always expire at intervals that are X amount time apart. The next expiry is determined at the point that IntervalTimerImpl::update() is invoked, not upon returning to io_service::run().

Are you proposing a third timer mode of some sort? Please elaborate.


comment:3 in reply to: ↑ 2 Changed 2 years ago by fdupont

Replying to tmark:

There are currently two modes, ONESHOT and REPEATING. You seem to be talking about when a timer is in REPEATING mode.

=> no, I talk about all timers.

I believe that this functions as designed. The intent is for the timer expire at fixed intervals, not intervals relative to what happens fter the timer expires. In other words, once started, and unless modified it should always expire at intervals that are X amount time apart. The next expiry is determined at the point that IntervalTimerImpl::update() is invoked, not upon returning to io_service::run().

=> my concern is about the code which don't use io_service::run().

Are you proposing a third timer mode of some sort? Please elaborate.

=> if you have a timer for in 1 hour, getInterval() will return 1 hour now, 1 hour in 30 minutes, 1 hour in 59 minutes. So if you use this 1 hour value to wait for some events and nothing happens you will be late. The issue is what you want is remaining delay, not the interval.

comment:4 follow-up: Changed 2 years ago by tmark

So you are simply proposing to expose the expiry time via a getter method to return the value? If so that's fine but 1.0 is full, this would likely end up in the outstanding queue.

comment:5 in reply to: ↑ 4 Changed 2 years ago by fdupont

Replying to tmark:

So you are simply proposing to expose the expiry time via a getter method to return the value?

=> yes (in fact it should be the relative expiry time but the difference doesn't matter).

If so that's fine but 1.0 is full, this would likely end up in the outstanding queue.

=> anyway as the bug should appear only when there is no traffic so when it can't lead to bad effects the ticket could never get a more than low priority...

comment:6 Changed 2 years ago by hschempf

  • Milestone changed from Kea-proposed to DHCP Outstanding Tasks

per team meeting on 23 sept, move to outstanding

comment:7 Changed 2 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to Outstanding Tasks

Milestone renamed

Note: See TracTickets for help on using tickets.