Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to sched_setscheduler parameters and calling that service
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to sched_setscheduler
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to sched_setscheduler
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to sched_setscheduler
Philippe Gerum wrote:
AFAIC, I don't see how changing priorities on the fly within a time critical
section could be considered as good programming practice; this would tend to
indicate that somebody is playing with priorities to paper over an application
design issue.
So, you mean PIP papers
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
AFAIC, I don't see how changing priorities on the fly within a time critical
section could be considered as good programming practice; this would tend to
indicate that somebody is playing with priorities to paper over an
application
design
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
AFAIC, I don't see how changing priorities on the fly within a time critical
section could be considered as good programming practice; this would tend to
indicate that somebody is playing with priorities to paper over an
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes.
Philippe Gerum wrote:
Jan Kiszka wrote:
So we should warn the user (in the doc) that rt_task_set_priority will
leave an inconsistent priority distribution between Linux and Xenomai
behind? But what is that propagation path in xnpod_renice_thread_inner
good for then?
A failed attempt that
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
AFAIC, I don't see how changing priorities on the fly within a time critical
section could be considered as good programming practice; this would tend to
indicate that somebody is playing with priorities to paper over an
application
design
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
So we should warn the user (in the doc) that rt_task_set_priority will
leave an inconsistent priority distribution between Linux and Xenomai
behind? But what is that propagation path in xnpod_renice_thread_inner
good for
13 matches
Mail list logo
