Philippe Gerum wrote:
Steven Seeger wrote:
All right, all right. I surrender. *waves the white flag*
Let's just say that I saw something different from fusion/classic RTAI
and
was reporting it as a possible bug incorrectly, all right?
Right (except that fusion never exhibited the behaviour you described,
though). Still, there is an interesting question that remains which you
indirectly brought in, and which is the real issue to worry about: does
rt_task_wait_period(), as it is now, behave in the best interest of
users who happen to use it properly?
I mean: if the application misses several deadlines because something is
going wild in there, wouldn't the recovery procedure be easier if one
knows at once how many deadlines have been missed in a raw,
"in a row". Typical froggie English, sorry.
without
having to call the RTOS back. IOW, do we want to purge the overrun count
after the first notification and make rt_task_wait_period return this
count (e.g. ala Chorus/OS's thread pools), or would it be preferable to
keep the things the way they are now?
Breaking the API again is also an issue, albeit we already broke it for
a few other calls when working on v2.1 anyway.
Open question. Something like a poll, actually.
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
