In the early days of development, Stargate engine ran as setuid or setcap and was able to give it's worker threads a high priority. Fast forward a few years, and security engineers have managed to ruin everything, as they often do. Specifically, the "problem" is that Stargate UI is written in Python, and manages the engine process which is written in C and wants elevated scheduler priority. Some highly overpaid security engineer concluded that only script kiddies would write a Python script that invokes a binary that wants to run with elevated permissions, and decided the best way to deal with this was to kill the process before it can even begin to execute.
Apparently compiling a binary with #include <sched.h> and then either giving the executable or the user permissions to change the scheduler is enough to trigger this behavior. Running the same executable from a terminal by hand will work, and will be able to change the scheduling, it's only invoking it from Python that is problematic.
Which left the following choices:
Don't #include <sched.h>, and don't attempt to modify the priority. This is what is currently happening, and Stargate is so performant without any scheduler priority bump that it's not a problem.
RtKit: Unfortunately, this is a useless solution for DAW work because of this
Create some kind of daemon to manage subprocesses and thread priority ourselves. Because nobody would ever question the decision to run a daemon as root :roll_eyes: . But this adds a huge amount of complexity and actual real security risks, and quite frankly it's silly to run a daemon at all times for a user application.
In conclusion:
The lack of scheduler optimizations is very unlikely to encumber your ability to make music
If it bothers you, learn that it shouldn't , or else complain to your distro + upstream security packages
In the early days of development, Stargate engine ran as
setuidorsetcapand was able to give it's worker threads a high priority. Fast forward a few years, and security engineers have managed to ruin everything, as they often do. Specifically, the "problem" is that Stargate UI is written in Python, and manages the engine process which is written in C and wants elevated scheduler priority. Some highly overpaid security engineer concluded that only script kiddies would write a Python script that invokes a binary that wants to run with elevated permissions, and decided the best way to deal with this was to kill the process before it can even begin to execute.Apparently compiling a binary with
#include <sched.h>and then either giving the executable or the user permissions to change the scheduler is enough to trigger this behavior. Running the same executable from a terminal by hand will work, and will be able to change the scheduling, it's only invoking it from Python that is problematic.Which left the following choices:
#include <sched.h>, and don't attempt to modify the priority. This is what is currently happening, and Stargate is so performant without any scheduler priority bump that it's not a problem.In conclusion: