[pulseaudio-discuss] rtkit: add pid as argument

Maarten Lankhorst m.b.lankhorst at gmail.com
Sat May 8 02:21:50 PDT 2010


2010/5/7 David Henningsson <launchpad.web at epost.diwic.se>:
> On 2010-04-25 22:11, Lennart Poettering wrote:
>> On Sun, 25.04.10 21:41, David Henningsson (launchpad.web at epost.diwic.se) wrote:
>>>> which handle corresponds to the thread, or even if that handle is local
>>>> or not. Wineserver controls this information so all requests that
>>>> involve handles involve a wineserver call, in general. So racing cannot
>>>> happen, because wineserver is the only one making the requests.
>>> Just a question, what about RLIMIT_RTTIME, which rtkit requires to be
>>> set for enabling rt? AFAIK there is no equivalent in Windows.
>> Well, we enforce RLIMIT_RTTIME mostly because we can, not because it
>> would really inhibit all kind of RT-related misbehaviour of the clients.
>> Or in other words: RLIMIT_RTTIME is quite useful as a protection against
>> programming errors somewhre, however it is still easily circumventable
>> by people who really try to do evil things, unless combined with other
>> tricks, such as SCHED_RESET_ON_FORK.
> So let my rephrase my question to Maarten: Since there is no equivalent
> to RLIMIT_RTTIME in Windows, applications might assume they can run in
> RT for extended periods of time. This might be considered bad
> application behavior in any operating system, but nonetheless - do we
> risc regressions when these applications are being killed, instead of
> the previous behavior which just let them run in non-RT?
I don't think this will happen, if it is going to I will handle
SIGXCPU in wine, and just demote all realtime threads back to normal
priority when that signal is sent by the kernel.


More information about the pulseaudio-discuss mailing list