Jan Kiszka wrote: > (..) > Now I wonder how to resolve this, how to make pthread_setschedparam (a > rather central RT-service) really real-time safe? I would say we need > something like a lazy schedparam propagation to Linux which only takes > place when the thread enters secondary mode intentionally or no other RT > thread is ready. But I do not have a design for this at hand. Nasty.
A simple solution is to wrap pthread_getschedparam as well. It would fallback to __real_pthread_getschedparam when the xenomai posix skin syscall returns -ESRCH. This would allow to remove the offending call to __real_pthread_setschedparam in __wrap_pthread_setschedparam. > > [My preferred way for every setup != CONFIG_PREEMPT_RT + CONFIG_XENOMAI > would still be to switch this prio-inheritance off for the root thread. > But this was nack'ed by Philippe several times before... ;)] > > Side note: the native skin does not seem to suffer from this effect as > it only tracks the current prio at Xenomai level. > > Jan > > > PS: Gilles, what about marking those services of the POSIX in the doc > that may issue a linux syscall (and under which conditions)? Actually, syscalls that may be called only from a particular context or that cause migration of their caller have a paragraph entitled "Valid contexts", if pthread_setschedparam lack this paragraph, it is probably because its implementation changed without its documentation. -- Gilles Chanteperdrix. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core