Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> 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: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>>>>>>> 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.
>> I may have misunderstood that this early statement in the discussion was
>> still valid after we dug deeper into the topic.
>>
>>>>> 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.
>> I understand the deep desire to keep the priorities in sync for those
>> threads that go to secondary mode (or at least accept occasional switches).
>>
>> But no one will (OK: should) seriously build a primary-only design based
>> on assumptions about the glibc locking and syscall behavior. Practice
>> teaches that this is doomed to break - at latest on next glibc update
>> (or what other standard third-party lib). Primary-only means only safe
>> Xenomai services or well-audited library calls. So turning some Xenomai
>> service into an unsafe one remains a critical step, even if it fixes
>> other use cases.
>>
>>> Ok. I am looking at the SIGWINCH change.
>>>
>> Great, TiA.
> 
> I am not optimistic. I see no way for now to change this without
> breaking the ABI.

Well, both the current change as well as a potential signal-based prio
update would be 2.5 material IMHO. So ABI breakage is not an issue. I
wouldn't touch 2.4 unless there is a transparent fix feasible (which I
doubt as well).

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to