Gilles Chanteperdrix wrote:
> 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.
> 

Mmh, may work. I guess we need some code now. I already rebased my
series over trunk, I could give this approach a try later.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to