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. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core