Tim Hockin <[EMAIL PROTECTED]> 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
