My linux user account is allowed to set realtime priority up to 90 ( “@rtprio 90” in /etc/security/limits.conf )
The JUCE timer thread is launched with a startThread(7) , which grants it (when allowed) a realtime priority of 70
I am not sure if the JUCE Timer thread should run with realtime privileges, and if it does, I don’t think it should run with such a high priority (these kind of priorities should be reserved for audio/midi)
It has a high priority so that it can be fairly accurate, as its job is just to wake up at specific times and send a message. It spends almost all its time sleeping so I don’t think this would be a problem, and an audio thread would actually be much higher (even needing to be a special class of thread on some OSes)
Well on linux, it is this special class of thread that the juce timer thread is using (SCHED_RR threads). It is not using SCHED_OTHER , and I think it should. If you look at the Thread::setThreadPriority(int priority) code, JUCE is using SCHED_RR as soon as the requested priority is > 0 , and I think it should not, at least not until the highest values of priority.
I must add that by default, linux distributions donot allow setting SCHED_RR priority for non-root users, so in these cases setPriority(7) will do nothing as the call to pthread_setschedparam will fail, and the juce timer ends up with the default priority.
Well, I guess it doesn’t really need to be that high, though maybe slightly higher than normal is probably a good thing. I might change that.
But like I said, I still don’t think it matters in practice, as the thread does very little work, it just wakes up occasionally and sends a message. It doesn’t actually run any timer code.