Tim Hockin <thockin(a)hockin.org> writes:
I apologizer if this has been discussed, but I
haven't read the whole
thread. Has the idea of a simple sched_rr helper been discussed?
Roger Larsson has an rt_monitor program that can do most of what you
suggest. It also limits the fraction of the CPU these threads are
allowed to consume. But, it can't handle mlockall(), and that's a
show-stopper for some (but not all) serious audio uses.
It can be setuid and only executable by a specific
group.
rtsched my_rt_app
setscheduler
drop privs
exec
I guess that doesn't help mlockall(), though. Hrrm.
Right. And it doesn't help when the program wants to create a
realtime thread later, like all JACK and PortAudio applications do.
--
joq