[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Fernando Lopez-Lezcano]

On Sun, 2009-06-21 at 19:14 -0400, Paul Davis wrote:
> On Sun, Jun 21, 2009 at 7:06 PM, Fernando
> Lopez-Lezcano<nando at ccrma.stanford.edu> 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.

Without reading code it sounds from the description of RealtimeKit that
it is designed to avoid exactly the kind of thing Jack does routinely,
that is to grant rt scheduling to threads that belong to other processes
(the Jack clients). 

-- Fernando


> 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().