Re, [email protected], le lun. 27 avril 2026 00:07:11 +0100, a ecrit: > From: Diego Nieto Cid <[email protected]> > > Leave max_priority uninitialized (0) so that when > a thread is created it inherits the max priority > from the processor set.
I'd rather set it to BASEPRI_SYSTEM, to avoid going lower than kernel threads etc. > This should not change any behaviour (except allowing > inheritance) because the default max_priority of a > processor set is also BASEPRI_USER. Which I advised to lower to BASEPRI_SYSTEM too :) It's rather in boot_script_task_create that we'd want to set the max_priority to BASEPRI_USER, so that userland inherits it by default, including root, while letting it go down from that. > --- > kern/thread.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/kern/thread.c b/kern/thread.c > index deb9688d..0e753d7a 100644 > --- a/kern/thread.c > +++ b/kern/thread.c > @@ -335,7 +335,14 @@ void thread_init(void) > thread_template.swap_func = thread_bootstrap_return; > > /* thread_template.priority (later) */ > - thread_template.max_priority = BASEPRI_USER; > + /* > + * Setting a max_priority here prevents inheritance > + * from higher priority tasks to its threads. > + * > + * BASEPRI_USER will be set nonetheless as it's the > + * default value of the task processor set. This last comment is confusing, the reader is wondering where it will be set. Just making the field BASEPRI_SYSTEM and saying that it's a priori the base max priority for thread is enough. > + */ > + thread_template.max_priority = 0; > /* thread_template.sched_pri (later - compute_priority) */ > #if MACH_FIXPRI > thread_template.sched_data = 0; > -- > 2.53.0 > >
