Jan Kiszka wrote:
> 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?
>> I believe Philippe already fixed that in trunk.
> Hmmm... but we are on trunk, just a few weeks old...
> The scenario, as far as I understood it, is that rt_task_set_priority is
> called from primary context. But the propagation in
> xnpod_renice_thread_inner targets relaxed contexts only. Probably that's
> the core of the issue. We need to propagate the modification when
> migrating next time. Maybe some flag "update Linux prio" so that we only
> go that way when actually required.
> BTW, strike my idea of using plain sched_setscheduler - would kick us
> out of primary mode unconditionally.
No, you should use pthread_setschedparam, and yes, it will kick us out
of primary mode, but we decided that it was preferable to complicated
alternatives: pthread_setschedparam is the only way for libc to be
informed of the priority change. Libc has its only idea of what the
priority of a thread is, so, we can not change the priority only in the
Xenomai-core mailing list