Re: coreaudio-api digest, Vol 1 #146 - 10 msgs
Re: coreaudio-api digest, Vol 1 #146 - 10 msgs
- Subject: Re: coreaudio-api digest, Vol 1 #146 - 10 msgs
- From: Brian Willoughby <email@hidden>
- Date: Thu, 29 Nov 2001 16:05:46 -0800
[ >In 10.1, an ordinary process can't make an ordinary thread be higher
[ >priority than the window server (whose priority doesn't degrade either), so
[ >your ordinary thread will get pre-empted (or not scheduled in the first
[ >place) whenever the window server needs to do something.
[
[ Does this behaviour of 10.1 will remain in future versions of the
[ system?
[ If yes it means that the standard pthread API (using SCHED_FIFO)
[ can not be used for real-time audio. Is that correct?
This behavior is a security feature of Unix, so I hope it will remain in the
future. There is no other way to prevent Denial Of Service attacks by
mischievous persons.
If you really need to go beyond this, you can mark your application as setuid
root. Then the process will have more privilege. This requires that the
application be installed by someone who has root access to the machine, which
is basically a way of pointing out the fact that the user must trust the
developer that the program will not crash the machine. Once installed, a
normal user can run the program and it will have root abilities.
Note: I'm not saying that you *should* use root access to gain a higher
priority. It is probably better to use the time constraint scheduling
policy rather than simply boosting the overall priority very high. But I am
merely pointing out that there is a way around the priority limitations, but it
requires trust between the developer and user, as well as root access during
installation of the program. Plus, this is a very tricky development
technique, because it opens your application to a higher scrutiny for bugs and
back-doors since there is an increased need for trust.
Brian Willoughby
Sound Consulting