21 Jun
2009
21 Jun
'09
9:49 p.m.
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(a)ccrma.stanford.edu> wrote:
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
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().