Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Quick question $customer stumbled over: Shouldn't the user space part of
>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>> caller? My impression is yes. Actually, translating the native priority
>> to sched_setscheduler parameters and calling that service would be
>> better, no?
The nucleus does this for us, but that is not enough due to the glibc caching
> I believe Philippe already fixed that in trunk.
Mostly yes, but properly only for task creation/shadowing requests. There is
still a problem with the glibc caching the priority level with set_priority()
calls, since we only rely on the nucleus, without telling the glibc about the
change. However, this would trigger a secondary mode switch.
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 application
design issue. For that reason, enduring a mode switch upon
rt_task_set_priority() calls (and friends) would be ok for me. But that's
Xenomai-core mailing list