[ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

[michael at cherryblossom.homelinux.com]

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.

> >2) 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