On 01/03/06, Philippe Gerum <[EMAIL PROTECTED]> wrote:

 The other option I've described for
dealing with overruns in rt_task_wait_period would be as follows:

- save the count of overruns
- clear the count of overruns  /* i.e. "purge" */
- return both the saved count and -ETIMEDOUT to the user.

This way, rt_task_wait_period would return only once with an error status, telling
the user about the exact count of pending overruns in the same time.

I definitely agree with you here.

IMHO, there is no point in calling rt_task_wait_period() a few
times in a row just to clean up the "poverrun" counter
(if there were a few overruns) when the whole may be reported at once. This former way just gives unnecessary overhead.

Actually, there is a kind of application that must not rely on
the "poverrun" counter, the klatency/latency utility and alike.

They are run normally (at least at the very first time) in the untrusted environment
where SMI or something similar - that may prevent a CPU from handling normal
interrupts for quite a long time - make occur happily.
As the "poeverrun" counting is dependent on the timer interrupt,
it becomes irrelevant.

Something like
overruns = (real_time_of_wakeup - desired_time_of_wakeup) / period (*)
should be rather used there (of course, the timing source must not be

Other applications may likely rely on the "poverrun" counter
(returned by rt_task_wait_period(&overrun)) as they normally
run in the (more or less) studied and tweaked environment.

Ok, some "paranoid" programmers would think differently even then
but there is always the (*) way :o)

Best regards,
Dmitry Adamushko
Xenomai-core mailing list

Reply via email to