On Tue, Aug 31, 2004 at 10:54:46AM +0100, Mike Hearn wrote:
Hmm, so I suppose the idea of getting all wine processes nice 19 and then doing something internally to manage win's prios when it gets the CPU is out of the question, right?
It's an issue of performance vs. performance -- performance with syncronization and running priorities like Windows, and performace as in running as fast and efficcently as possible.
- After you've reduced a thread or process's priority, it's not
possible to elevate it to the original level again (without being root), so if a thread is set to low priority temporarily, it won't be possible to restore it to normal priority under Linux. Under Windows it's of course possible.
Hmm... and reinventing the wheel would be redundant, of course, I presume? Like having a sort of sub scheduler, that does Windows/Wine scheduling, within Wine, which is then scheduled in Linux?
Other solution is just to detect this and ask the user to rerun Wine as root. I don't think that'd be a big deal.
But then that brings up the issue of users not being able to run wine merely because they don't have root access, i.e. users on a Linux system in a business environment, or remote X/telnet access on a server with wine (for various reasons).
The idea of having to run under root was one of the ones why people avoid SVGAlib nowadays, and setuid/root will be a deep security risk considering what kind of apps we're looking at here. If we say, run notepad, we have a root editor application -- capable of messing with config files on the Linux setup -- something that the Linux admin might not want.
Personally, it would only affect me in that files generated by wine could be owned by root:root when I normally run under a user id, such as michael:michael or michael:windows or something.
For the time being, of course, the theory is that run as root should work okay.
If this is implemented, shouldn't this be a warning, not a forced thing? So that a normal user could (try and) run wine without root access? And I presume that this would be 2.6 specific detection - otherwise, there's not really a need (since Wine worked OK under 2.4 and such). We could say something like: "Wine has dectected that you are running Wine as a normal user under Linux kernel 2.6+. Due to changes in the scheduling mechanism in 2.6, which includes preempting and a change in the way process priorities are handled, Wine may not work properly, or different parts may work at different speeds, causing desyncronization of your application and/or it's components. You are suggested to <(run wine as root) or (downgrade and use a (2.4 kernel) AND/OR <supported kernels list>) or (list other workaround information)>."
So we're looking for a user-mode mechanism of temorarily changing priority or emulating/faking it as Windows does it, and then allowing the restoration of that priority to a higher value (not normally found in Linux except as root).
I presume that if someone wanted to get started writing a patch now using any one of these ideas, then we could just test it and see how it does among us, and then if it's okay, submit it, get it through CVS, see what happens, get it through a release if that happens, and then we can finish this debate only when performance issues or something else needs to be done about this.
I think that finally, we should allow the user to bypass this scheduling patch for 2.6 during development if he/she really wants to, but don't make it too easy, and when he/she does, warn that things like audio and video can come out of syncronization and programs can break and such. Or do you guys already do this?
Just trying my best. --Michael Chang