Re: after ids

On 7/7/08, Daniel A. Steffen <das@...> wrote:
> Hi Alexandre,
>
> On 07/07/2008, at 16:08, Alexandre Ferrieux wrote:
>
> > On 7/6/08, Daniel A. Steffen <das@...> wrote:
> >
> > >
> > > All the implementations of relative timers in the OS (nanosleep(),
> > > pthread_cond_timedwait_relative_np() etc) are based on
> this reference.
> > >
> >
> > So, the shell loop 'while :;do sleep 1;echo foo;done' should have
> > visible quirks when someone sets the date, right ?
> >
>
> no, why? that's a relative timeout, /bin/sleep relies on nanosleep() and is
> not affected by calendar time changes (i.e. settimeofday() or adjtime())
> the 'absolute' in mach_absolute_time() may be confusing matters, that's the
> monotonic time reference for relative time intervals (i.e. differences of
> m_a_t() values), whereas absolute timers are calendar time based.

You're right, I was confused :-}

> However, on Darwin at least it turns out that even the APIs that take an
> absolute time to wait (like pthread_cond_timedwait()) in fact just wait for
> the relative interval to the value of gettimeofday() at the start of the
> call (i.e. if calendar time is adjusted/changed during the waiting, the
> kernel does not update the timeouts AFAICT).

OK, so pthread_cond_timedwait is equivalent to the timeout in select()
after all.
The reform can wait 

> However, if you actually want absolute timers (as the current [after]
> implementation appears to), using select() may be incorrect unless you can
> find a way to be woken up when the gettod base changes. On Darwin a host
> notification is sent when calendar time is changed via settimeofday() (but
> not for adjustments due to adjtime()), I don't know if something similar
> exists on other platforms.

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

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]).
Then, whenever the notifier is preparing for bed, recompute the
relative time of the first of each queue, take the min, and sleep for
that.

Of course the periodic watchdog above can be integrated in this
scheme. Even without looking at gettod itself, by the simple fact that
it forces the notifier to recompute the next time-jump frequently,
this method would guarantee the timely firing of absolute timers even
in drastic settod conditions.

(Notice that while we qualify today's [after] as absolute, it will
only track a settod *if* some event source (timer or not) wakes us up
frequently enough. Kevin was in this case if I understand correctly.)

-Alex

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