Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Author: gch
>>>>> Date: Sat Oct  4 23:11:09 2008
>>>>> New Revision: 4210
>>>>> URL:
>>>>> Log:
>>>>> Call __real_pthread_setschedparam in order to inform the libc of the 
>>>>> scheduling parameters change.
>>>> Well, I dropped this idea after realizing that it will kick us out of
>>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>>> scheduling accuracy) for borderline threads, but it will cause
>>>> regressions for primary-only threads. I have no idea right now how to
>>>> make both happy, at least without explicit pthread_setschedparam
>>>> invocations by the user application.
>>> Well, we discussed this on the xenomai mailing list, you did not answer,
>>> so we assumed you agreed.
>> I do not find any hint in that thread that we agreed on changing the
>> implementation. Rather I took back my suggestion to do it like #4210.
>> And you proposed to install some signal for syncing glibc /wrt
>> priorities. When changing something, then I would say explore this path
>> first.
> We are used to hear you when you do disagree... So, since you did not
> answer Philippe mail who said "it is certainly debatable", we assumed
> you agreed. But we certainly were wrong.
>> Turning rt_task_set_priority into secondary-mode service is a critical
>> change, and only the last resort if we consider its current
>> implementation as totally broken - I wouldn't say it is like that. It's
>> partially and, unfortunately, silently broken, ie. lacking documentation
>> about its limitations. But its perfectly OK for primary-only users.
> No, an important invariant of Xenomai is that the priority scales are
> synchronized between Xenomai and Linux. So, if Linux does not see the
> same priority as Xenomai, the implementation is broken. Imagine for
> instance that your primary-only thread posts an NPTL semaphore, knowing
> that a switch will not occur so that it will not leave primary mode. If
> the glibc does not see the correct priority, then a mode switch may
> occur whereas it should not. This is a bit far-fetched, but who knows
> what else may happen if the priorities are not synchronized. We
> absolutely want the priorities to be synchronized.

Ok. I am looking at the SIGWINCH change.


Xenomai-core mailing list

Reply via email to