Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Hi Gilles, >>>> >>>> here is a trivial test case on my desk that points to SCHED_RR issues of >>>> the POSIX skin: simple pthread_create with an attribute block that has >>>> SCHED_RR set, but neither SCHED_RR nor the priority reach the new thread. >>>> >>>> The way the scheduling policy and parameters get to that user space >>>> thread leads via __real_pthread_setschedparam after >>>> __pse51_thread_create. This triggers do_setsched_event in shadow.c. But >>>> here we filter out all policies except for SCHED_FIFO. So neither the >>>> priority nor the required XNRRB flag make it to the target therefore. >>>> >>>> Even worse, we are running aperiodic timer mode, so this would not have >>>> worked anyway due to the scheduler limitations. Fortunately, it turned >>>> out that the customer is fine with SCHED_FIFO as well, but the broken >>>> priorities and/or lacking error codes on creation are annoying + the >>>> fact that it likely wouldn't work even with periodic timer mode. >>> The fact that it does not work with aperiodic timer is documented. >>> However, this used to work and was tested with periodic timer (you can >>> find the tests under sim/skins/posix/testsuite), that is why there is no >>> reason to return any error code. >> ...which is bogus IMHO. Expecting to read the doc when something does >> not work as expected is ok. But more or less silently failing even if it >> is documented that it will somehow fail is not what Xenomai is usually >> known for. >> >> That said, I still don't see (looking at TRUNK) how SCHED_RR should work >> even under periodic mode. Guess I have to enable and test it. >> >> But I guess the best we can do is to finally remove this limitation by >> allowing the use to create a periodic tick timer over aperiodic mode if >> there is a need for RR scheduling. > > In ksrc/skins/posix/syscall.c, function __pthread_create: > > pthread_attr_init(&attr); > attr.policy = p->policy; > param.sched_priority = p->rt_priority; > attr.detachstate = PTHREAD_CREATE_DETACHED; > > So, the priority and policy are taken from the underlying Linux thread.
Yep, but its prio/policy is set *after* the chunk above. Maybe it is already a sufficient hot-fix to move __real_pthread_setschedparam before __pse51_thread_create if this has no unwanted side effects. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
