Re: [RFC/RFT] calloutng

On Wed, 2013-01-02 at 15:11 +0200, Alexander Motin wrote:
> 02.01.2013 14:28 пользователь "Luigi Rizzo" <rizzo_at_iet.unipi.it> написал:
> >
> > On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote:
> > > On 02.01.2013 12:57, Luigi Rizzo wrote:

> > First of all, if you know that there is already a hardclock/statclock/*
> > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet
> > was ""no event scheduled in [T_X, T_X+D]" so you need to generate
> > a new one.
> 
> That is true, but my main point was about merging with external events,
> which I can't predict and the only way to merge is increase sleep period,
> hoping for better.
> 

This really is the crux of the problem, because you can't *by default*
dispatch an event earlier than requested because that's just a violation
of the usual rules of precision timing (where you expect to be late but
never early).

Sometimes there is no need for such precision, and an early wakeup is no
more or less detrimental than a late wakeup.  In fact, that may even be
the majority case.  I wonder if it might make sense to allow the
precision specification to indicate whether it needs traditional "never
early" behavior or whether it can be interpretted as "plus or minus this
amount is fine."  Like maybe negative precision is interpretted as "plus
or minus abs(precision)" or something like that.

Or maybe even the other way around... you get "plus or minus" precision
by default and the few things that really care about precision timing
have a way of indicating that.  (But in that case the userland sleeps
would have to assume the traditional behavior because that's how they've
always been documented.)

-- Ian