Philippe Gerum wrote: > On Tue, 2007-01-02 at 14:30 +0100, Gilles Chanteperdrix wrote: > >>Philippe Gerum wrote: >> >>>On Tue, 2007-01-02 at 11:20 +0100, Jan Kiszka wrote: >>> >>> >>>>Hi all - and happy new year, >>>> >>>>I haven't looked at all the new code yet, only the commit messages. I >>>>found something similar to my fast-forward-on-timer-overrun patch in >>>>#2010 and wondered if Gilles' original concerns on side effects for the >>>>POSIX skin were addressed [1]. I recalled that my own final summary on >>>>this was "leave it as it is" [2]. >>>> >>> >>> >>>The best approach is to update the POSIX skin so that it does not rely >>>on the timer code to act in a sub-optimal way; that's why this patch >>>found its way in. Scheduling and processing timer shots uselessly is a >>>bug, not a feature in this case. >> >>There is some work to be done on the posix skin anyway, this will all be >>at once. By the way, I tested the trunk on ARM, and I still get a lockup >>when the latency period is too low. I wonder if we should not compare to >>"now + nkschedlat", or even use xnarch_get_cpu_tsc() instead of "now". > > > You mean as below, in order to account for the time spent in the handler(s)? > > - while ((xntimerh_date(&timer->aplink) += timer->interval) < now) > + while ((xntimerh_date(&timer->aplink) += timer->interval) < > xnarch_get_cpu_tsc()) > ; >
I mean even: while ((xntimerh_date(&timer->aplink) += timer->interval) < xnarch_get_cpu_tsc() + nkschedlat) ; Because if the timer date is between now and now + nkschedlat, its handler will be called again. -- Gilles Chanteperdrix _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core