[LAD] QTractor: QThreads: Not realtime on Linux without root?

[Rui Nuno Capela]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20161226/c0b08956/attachment.pgp>