Hi,
I've been doing some research on why task_priority (5, TRUE)
fails. And it happens that, while the task priority does not
have a "max" (task_priority will set whatever valid priority
you throw at it), threads do.
And from the following grep results, a thread is born with
a max priority of BASEPRI_USER (25)
kern/sched.h:141:#define BASEPRI_USER 25
kern/task.c:179: new_task->priority = BASEPRI_USER;
kern/thread.c:338: thread_template.max_priority = BASEPRI_USER;
kern/thread.c:422: *new_thread = thread_template;
which can be further restricted by the processor set its task
is running on.
But assuming the baseline of BASEPRI_USER, 5 (the kernel side
mapping of user priority -20) is already too low. And while
root should be able to reduce the priority, task_priority
(with change_threads TRUE) is not giving such functionality.
Thus, setpriority(PRIO_PROCESS, 0, -20) will fail for root, too.
So, not sure how to proceed here. Maybe userspace can fiddle with
pset and task priorities or a new RPC may be introduced in gnumach
where all settings could be updated in an "atomic" way.
Regards,
Diego
