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. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
