Gilles Chanteperdrix wrote: > Hi, > > I am working on using SIGWINCH to trigger priority changes in > user-space. And I am afraid it will never really work: > - Xenomai makes a difference between the base priority of a thread and > its current priority. But pthread_getschedparam should return the base > priority, not the current priority, so, we need a way to change the > current priority of a thread without changing its base priority. > - I do not know at what time we should trigger a signal to the thread > whose priority is changing: > . if we send it as soon as we return to user-space (at the same time > as when we handle LO_RENICE_REQ), if the thread whose priority is > changing is not the current one, we potentially trigger a > primary/secondary mode transition for this thread; > . if we wait for the target thread to return to secondary mode (via > xnshadow_relax), any other thread in the same process which would read > the target thread priority with pthread_getschedparam would not see that > the priority has changed; > . we could do it as soon as a thread of the same process returns to > secondary mode, but it looks complicated, and besides, > pthread_getschedparam can safely be called from primary mode, so we > still have the same issue as for the previous point. > > This is where I stopped thinking about this idea.
It would be nice to have pthread_getschedparam always in sync with the shadow base prio. But if this is obviously at least very complicated (if not infeasible), I would focus on getting the base prio right when the thread switches to secondary mode (or if it already is there, of course). That we cannot guarantee pthread_getschedparam returning the same value that rt_task_set_priority applied should simply be documented. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
