Re: after ids

On 07/07/2008, at 21:16, Alexandre Ferrieux wrote:

> Now what about the following hack: have a coarse-grained periodic
> task (say every 5 sec or so), based on a relative timer (!), that
> checks for dicontinuities in gettod() (among others, it would kick in
> everytime the machine is woken up from hibernation). Wouldn't that be
> an appropriate replacement for your systemwide event ? The idea being
> that when gettod is changed, precision under a few seconds is no
> longer a concern anyway...

agreed, feasible (if possibly somewhat expensive) fallback for systems  
where there is no gettod base change notification.

> Regarding your other question: what to do with a mix of relative and
> absolute timers ? Simple: have two queues of timer tokens, one with
> targets expressed in ticks (for the relative timers), the other with
> targets in gettod (for the absolute ones, just like today's [after]).

sure, that wasn't the question 
I was asking (before I figured out that pt_c_tw is internally also  
relying on a relative timeout) how the notifier should wait for both  
relative as well as absolute timeouts with a single API call, in the  
face of gettod base changes; the answer appears to be to use a  
relative timeout and listen to gettod base change notification (or  
fallback to your periodic gettod check timer above)...

Cheers,

Daniel

--

-- 
** Daniel A. Steffen                   **
** <mailto:das@...>  **


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08