[LAD] QTractor: QThreads: Not realtime on Linux without root?
Felipe Ferreri Tonello
eu at felipetonello.com
Tue Jan 3 18:31:03 UTC 2017
On 26/12/16 00:58, termtech wrote:
> Hi list. Hope Rui gets this...
> I have a puzzling technical question, involving QTractor.
> I have been looking very closely at how Qt's class QThread works.
> Actually, it doesn't. On Linux. As a normal user.
> A long investigation into its source code and ultimately some test programs,
> shows that on Linux it ignores what priority you attempt to start it with,
> if running with normal user privileges.
Yes, this is expected. See below.
> In Qt's qtbase/src/corelib/thread/qthread_unix.cpp:
> void QThread::start(Priority priority)
> pthread_attr_t attr;
> This code in Qt shows it initializes with default attributes which have
> scheduling 'other' and thus the range of priority levels is ZERO and thus
> QThread is lying about being at QThread::TimeCriticalPriority for example -
> it is NOT, it stored your requested level but did not actually set it.
> I just finished examining the following programs using 'htop' plus a
> custom program to ask what each's scheduling policy is,
> using pthread_attr_getschedpolicy():
> (With Jack running realtime etc. etc...)
> a) MusE : Two threads running FIFO policy (policy = '1'). Good, expected.
> MusE directly uses pthreads, and set policies and levels.
> I assume since I'm in the audio group with good rt limits,
> some help is going on, 'cause I ain't runnin' as root.
> b) QTractor : NO threads running FIFO (all policies = '0'). Bad? Unexpected?
> QTractor uses a few different QThreads with various priority settings
> including one requesting TimeCriticalPriority. Seem's it's not happening?
> c) Qt5Creator test program using QThread set to TimeCriticalPriority: Bad -
> thread has policy = '0'.
> The Mixxx project found the exact same thing:
> "RJ discovered that Mixxx's requests for real-time priority on this thread are
> having no effect. Running as a regular user on Linux shows that the priority
> range is from 0 to 0, and as root from 1 to 99, but it is set to 1 (the
> lowest) by default. However, calling
> setPriority(QThread::TimeCriticalPriority) (while running as root)
> does result in priority escalation. "
> A further look at the ticket shows they had to go with pthreads directly.
> What are your thoughts on this? Am I doing something wrong?
> Is QTractor really running realtime or not?
> After seeing the source and fooling with this, I'm disliking QThread.
> Before creating a QThread, I tried to elevate using seteuid, setegid
> and so on, and tried elevating to group 'audio'.
> Permissions denied, of course.
This is not a Qt problem - it is a user permission problem.
If sched_setscheduler() returns -1, check if errno is set to EPERM. In
this case the user trying to perform this operation does not have
CAP_SYS_NICE capability, which is *required*.
If you want this type of feature, set CAP_SYS_NICE to the group audio
that you are referring.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7177 bytes
Desc: not available
More information about the Linux-audio-dev