First check if we can adjust priorities with rlimits, if we can't and we
need to use rtkit, spawn a thread-loop to handle the rtkit stuff.
First do a pw_loop_invoke() to do the rtkit setup, including getting
some properties and then setting the nice level and rlimits.
Use pw_loop_invoke to queue rtkit realtime requests, this ensures we
always perform the requests after the setup and when the properties
are fetched.
See #3357
Don't block on the method calls to make realtime or high priority.
Those calls don't return anything and other errors (invalid method,
invalid arguments, no service,...) can be caught differently async.
Fixes#3357
Ask RTKit what the min nice level is and clamp our value to it to avoid
InvalidArgument errors.
Also add some more info messages when the level is clamped or invalid.
Fixes#3186
Refactor get_rt_priority_range().
When we can't set the requested priority, use rlimit to clamp it
and try again. If this clamped value is bigger than RT_PRIO_MIN,
we can allow this.
The result is that the RTPRIO is set to the max of the user rlimit
RTPRIO, as long as it's more than 11. Previously it would fall back
to RTKit.
The commit cited below mistakenly removed the set_rlimit call from under
`if (impl->use_rtkit)`, saying it doesn't have an rtkit implementation.
However, this function does call rtkit, so it has to be called in the
rtkit flow, otherwise pipewire fails to set the realtime priority,
printing the following error message:
mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
mod.rt: could not make thread #### realtime using RTKit: Permission denied
Fixes: 5ae1c03d77 ("module-rt: small fixes")
could_use_rtkit -> can_use_rtkit.
Only warn when setting nice and there is no rtkit fallback.
Always call set_rtlimit, it does not have an rtkit implementation, if just
has some properties with limits.
Only try to set nice again with rtkit when we required rtkit for some
functions.
Previously module-rt only checks if the user have the permission to use
realtime scheduling, and will unconditioally disable RtKit if they do,
even when they don't have the permission to set nice or rlimit.
pthread_getschedparam() always returns non-negative values, so checking
if its return value is less than zero always evaluates to false.
Also, pthread functions don't set errno. While logging a warning
message, use the return value of pthread_getschedparam() instead of
errno.
Make helper method to parse thread properties and add 2 new properties
to control name and stack-size of the thread.
Use properties when creating threads with the default utils.
Use the default thread utils instead of pthread_create so that the
properties are used.
Setting a global thread-utils is not a good idea, especially
when multiple contexts will register their own interface.
Instead, set the thread-utils as a context object and use this to
configure the data loop in the context.
In JACK we need a per context implementation of the interface so that
we can find the context specific thread-utils.
See #2252
The policy can of course be higher than zero if the current thread uses
anything other than `SCHED_OTHER`, and `SCHED_RESET_ON_FORK` needs to be
set according to the old policy or we'll either run into errors or cause
unwanted side effects.
There are a couple other ways to allow a user/process to use realtime
priviliges like `CAP_SYS_NICE`. Instead of trying to check every
possible factor, just trying if setting realtime priviliges works is
going to be a much cleaner solution.
Make the default nice.level an invalid value, that is not configured
as the priority on a process.
Explicitly enable a nice level on our daemon processes.
Fixes#2034
Because otherwise just looking at the rest of the output and seeing the
thread being set to priority 20 instead of the value that's set in the
config file may look a bit confusing.
I don't think PipeWire currently has a way to temporarily alias
module-rtkit to module-rt though, so right now this would break realtime
scheduling for people with modified configs that use module-rtkit.
