On 12/26/2016 12:58 AM, 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.
In Qt's qtbase/src/corelib/thread/qthread_unix.cpp:
void QThread::start(Priority priority)
{
...
pthread_attr_t attr;
pthread_attr_init(&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:
https://www.mixxx.org/wiki/doku.php/performance_improvements
"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.
that is an interesting finding Tim. but maybe not one of big concern.
you see, none of the qtractor subclassed QThread's needs to be real-time
at all. the only instance on that premises is, of course, the jack
process one, which is a regular pthread for all the real, real-time
scheduling class (FF) and on started jackd -P rtprio minus 5 points as
usual for all jack clients.
and actually, the issue is clearly stated in Qt documention, see
http://doc.qt.io/qt-5/qthread.html#setPriority
byee
--
rncbc aka. Rui Nuno Capela