[LAD] Realtime threads and security

torbenh torbenh at gmx.de
Fri Feb 25 15:56:24 UTC 2011


On Fri, Feb 25, 2011 at 10:29:45AM -0500, Paul Davis wrote:
> On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <list at samalyse.com> wrote:
> 
> > But let's take JACK for example. It handles setting up realtime scheduling
> > transparently when one creates a jack client. There isn't any extra step
> > necessary. As a supposition, could you imagine that ulatencyd integrates tightly
> > into JACK to provide fine-grained per-client realtime permissions?
> 
> ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
> with what JACK does. ulatencyd appearst to me concerned entirely with
> desktop latency and the notion that the "current app" (as represented
> by some form of ongoing user interaction) should be the most
> responsive. this has nothing whatsoever to do with the realtime
> scheduling that JACK is concerned with.
> 
> specifically, what JACK does is per-thread, and more significantly its either:
> 
>    * for threads that it creates (inside libjack) AND knows that they
> need to be RT
>    * for threads that the client specifically asks to be RT
> 
> you can't do this stuff on a per-process level.

also if cgroups on the system are properly configured, all the server
side needs to do is:

echo "$TID" >/mnt/cgroups/cpu/rt_goup/tasks

i dont think you need a lua interpreter for that :>

> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn



More information about the Linux-audio-dev mailing list