Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> AFAIC, I don't see how changing priorities on the fly within a time critical
>> section could be considered as good programming practice; this would tend to
>> indicate that somebody is playing with priorities to paper over an
>> design issue.
> So, you mean PIP papers over application design issues ? Just kidding...
PIP means, "well, you know what, I don't want to deal with dynamic resource
conflicts in my application, I don't want to bother defining a ceiling priority
for each of those resources, actually, I'm just unable to tell how they might
interact anyway, so please, beautiful and inspired kernel, GET THIS DAMNED THING
RIGHT FOR ME! Oh, and thank you."
But hey, that's fine! Nothing prevents the kernel from doing the smart job,
>> For that reason, enduring a mode switch upon
>> rt_task_set_priority() calls (and friends) would be ok for me. But that's
>> certainly debatable.
> Actually, we could trigger a signal for pthread_setschedparam to be
> called for next switch to secondary mode. We could re-use the signal
> already used to trigger a switch to primary mode for suspending a thread
> running in secondary mode, finding a way to multiplex the information
> passing, for instance, parameters to the siginfo structure.
Yep, that would work.
Xenomai-core mailing list