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.
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
