Implement SetThreadPriority

[Chris Robinson]

On Thursday 03 August 2006 04:57, you wrote:
> Allowing Windows
> apps to use priorities that can hang the box is not acceptable,

I can't help but think the kernel devs themselves disagree, since they 
explicitly added in this very "ability" for normal Linux apps (it's not like 
they can fully lock up the system without kernel access; the magic sysrq keys 
will always be available if it gets that bad). Besides, there's many other 
things a Windows app can do through Wine to bring the system to a screaching 
halt (some much more likely to be effective, even on a typical default 
configuration). Thread/process bombing, allocating almost all (RAM+swap) 
memory than the user has, creating/copying large files, etc. Such things that 
would need to be explicitly protected against by the user/sysadmin, unlike 
this which would need to be explicitly allowed. I hardly think CPU hijacking 
is high up on the list of potential attacks, especially since it'd be simple 
for the sysadmin to have an emergency process running that takes a higher 
priority than anything a user could set (or even simpler, alt-sysrq-k on the 
process's vt).

If the goal is to make Windows apps run transparently along normal native 
apps, then Wine should be able to do the same things that a native app can 
do. If native apps can set a real-time thread, then there shouldn't be 
anything stopping Wine from doing the same when the program asks for it.

> and 
> it's certainly not a viable solution to the sound problems.

I think it's *exactly* the solution to the sound problem. The reason the sound 
is so crappy is because you can't gaurantee that a thread will run when it 
needs with the attention it needs. You cannot get this without changing the 
thread's priority to preempt lesser priority threads and processes. Threads 
don't set THREAD_PRIORITY_TIME_CRITICAL just because it looks good to the 
user, after all. If a thread is set as time-critical, it means it's 
time-critical.

And it's not limited to just audio, either. Other things can be done in 
time-critical threads that are expected to preempt lesser threads. Hacking 
together a cludge for audio won't always help (and can potentially worsen) 
other situations.

Wine needs to duplicate Windows' features (including the bugs ;)) if it wants 
to successfully handle the majority of Windows applications properly. 
Sometimes that's dangerous/risky, but thankfully it's not like Wine will be 
able to set high priority threads willy-nilly. The sysadmin has to have it 
allowed for the user, in which case its not just Wine they need to worry 
about, and the stability of the system is in their hands.