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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev