LWN.net Logo

DBus

DBus

Posted Jul 2, 2009 4:34 UTC (Thu) by salimma (subscriber, #34460)
In reply to: DBus by jwoithe
Parent article: RealtimeKit and the audio problem

It should not be affected by SCHED_RESET_ON_FORK -- the wrapper will just exec, not fork.


(Log in to post comments)

DBus

Posted Jul 2, 2009 5:08 UTC (Thu) by jwoithe (subscriber, #10521) [Link]

Hmm, on reflection that is true - we're talking exec(), not fork().

However, there could be another issue. As I understand it, rtkit doesn't grant the requesting process permission to set an RT priority though sched_setscheduler(). Instead it grants a requested RT priority to the process. In other words it functions as a replacement for sched_setscheduler(). As I previously explained, many high-performance audio applications (for example, ardour, jack) are multithreaded and request different scheduling algorithms and priorities for different threads. The simple wrapper application would only be able to grant a single RT priority to what would become the audio application's main thread. That application (or any of its threads) would not be able to alter that priority (or maybe even drop RT scheduling).

Having a single global RT priority for all threads isn't flexible enough to ensure smooth operation of these applications (and in fact, in most cases only a few carefully chosen threads need to run at RT priority anyway).

Regards
jonathan

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds