On Sun, Jun 21, 2009 at 7:06 PM, Fernando
Lopez-Lezcano<nando@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Jun 22 04:15:03 2009
This archive was generated by hypermail 2.1.8 : Mon Jun 22 2009 - 04:15:04 EEST