Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > > I am thinking again about this patch: some handlers need to be
> > > > rewritten, for example the posix timers handler, because the handler
> > > > relies on the fact that it is called for every timer expiry to compute
> > > > the overruns count. So maybe this patch should come with the addition
> > of
> > > > an xntimer_getoverrun service that computes the overrun count using
> > the
> > > > tsc ?
> > > >
> > >
> > > Mmh, that gets close to hrtimer_forward now: push an overdue timer to an
> > > expiry date that is in the future and return the number of overruns. But
> > > do we still want this optimisation of the broken path then? It starts
> > > getting complex, probably adding more code than it is worth. I'm
> > > starting to vote against my own patch...
> >
> > The code to compute the number of overruns from the tsc exists in
> > xnpod_wait_thread_period, is not this just a matter of refactoring this
> > code in an xntimer_getoverrun ?
> >
>
> That overrun calculation takes place in thread context, we were
> discussing this for the timer handler. That means, if we generalise, we
> would have to pass the overrun counter somehow from the handler to the
> awakened thread. Would take another struct field, probably in xnthread.
> On the other hand, if that could save code in the posix skin, it may
> make sense.
What I had in mind was that timer handlers or threads that are
interested in the overruns count could call xntimer_getoverruns, which
computes the overruns count "on-the-fly" using the tsc, i.e. without
requiring any additional field.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
