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.
Let the module-rt and module-rtkit provide a new pw_thread_utils
implementation.
The pw_thread_utils interface has many advantages over the old way
of boosting the thread:
1. Does not require to add a source to the loop and do priority
boost in-thread.
2. Works on simple threads without data-loop interface.
3. Allows dropping RT priority as well.
The rtkit implementation requires a bit more work because there is
currently no pthread API to map an pthread to a tid. We make a small
wrapper thread to capture the tid with getpid() to do the mapping
ourselves. This should go when the new API arrives. See also:
(https://sourceware.org/bugzilla/show_bug.cgi?id=27880)
200ms seems a little small, some plugins initialize themselves from the
RT thread and get killed. 2 seconds seem to be a better default.
The important part is that there is a limit so that runaway processes
are killed and don't lock up the system.
Fixes#1344
