Hello, 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. Cheers, Maarten
