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.