Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> 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
>> kernel.
> So we should warn the user (in the doc) that rt_task_set_priority will
> leave an inconsistent priority distribution between Linux and Xenomai
> behind? But what is that propagation path in xnpod_renice_thread_inner
> good for then?

A failed attempt that used to work before the glibc folks decided to cache the
priority level of threads locally. With the NPTL, it's useless and error-prone.

> Jan


Xenomai-core mailing list

Reply via email to