http://defect.opensolaris.org/bz/show_bug.cgi?id=11784
--- Comment #12 from Michael Hunter <michael.hunter at sun.com> 2009-10-07 17:02:07 UTC --- (In reply to comment #5) > (In reply to comment #4) > > What is wrong with doing it right now? You don't know if there is an alarm > > scheduled soon. The event added could have been the one that was in the > > past > > due to scheduling delays. > > If the event we are enqueueing is the first event in the timed event queue, > then it is scheduled to go off "when" seconds from now (event->event_time = > now > + when). > > If the first event in the timed event queue has 0 seconds remaining, then it's > alarm must already be set, either in nwamd_event_enqueue_timed() (if it was > the first when it was enqueued) or in nwamd_event_enqueue_expired_events() > (when events expiring before it were dequeued). now = 0.2, whjen = 1 queue has event at t=1, alarm for 1s now = 1.0, when = 1 queue has event at t=1 (only been .8s) we are adding an event time 1 from now queue now looks like event at time t= 1 (leading to a delta of 0), and t = 2 We leave the timer alone and it will go off which I guess is fine. If this second call is actually at t = 0.9 then we end up pushing the timer forward a second. This is all a feature of using second granularity. Not sure it is intuitive and it is contrary to your statement above. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
