On Sun, Jun 21, 2009 at 7:06 PM, Fernando Lopez-Lezcano<[email protected]> wrote:
> If I understand correctly then the mechanism would not be useful for > jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack > actually gives rt priority to threads in other processes (the clients of > jack). But maybe things have changed in the way jack works internally > these days, or, possibly I'm not completely understanding the > implications... hmmmmm... jack does not do any forking right? that's correct. there is no fork involved in setting up RT threads inside JACK and even less for its clients. i don't believe that lennart's RTKit relies on this though. The idea is that a priviledged service is asked to give RT scheduling to a thread, but because of Ingo's patch, it can grant it knowing that any forked children will not also have RT scheduling. of course, the name of lennart's new feature doesn't make it entirely clear whether or not "fork" is equivalent to its "real" linux implementation: clone. if it were not, then you could create an "RT thread bomb" instead of a "fork bomb". i only did a quick reading of his patch and in the context of the patch its not clear whether it applies to every instance of clone() (i.e. thread or task creation) or just plain fork(). --p _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
