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

[Jeremy White]

Fyi,

I spent a great deal of time this past fall exploring Wine scheduling
issues, and I thought I would post what I learned.

The most critical point is Wine was pretty badly broken;
it simply had a number of flaws in how scheduling was done.

First, the winmm timer, used by a lot of programs,
was pretty awful.  That has now been fixed, and I believe
that it now works correctly.

Second, we did not synchronize Wine message times with X11
message times properly.  Fixing that resolved some issues
with Photoshop (and given that Ove reworked that patch into
WineX the same day I submitted it, I'd guess it fixed some
games too <grin>).

Third, Wine did not yield the processor properly at points
where Windows does, including Sleep(0) and certain event
conditions.  That's now been (mostly) fixed, I think.

Fourth, the Wine server had an issue with the way it managed
it request queues.  To be honest, I don't understand this
bug or the fix; all I know is that Mike McCormack figured
this one out and posted a magic fix.  This was, I believe,
the primary reason that the wineserver would chew 100% cpu
with iTunes.

Beyond that, there are a number of ways that Wine
'gets lucky' and Just Works (TM) works on the Linux scheduler,
in ways that we couldn't have asked for.

First, because many Wine calls resolve into a wineserver
call, and a wineserver call involves a write to a pipe,
we potentially risk yielding the processor far more often
in Wine that a Windows program would 'naturally' do so
on Windows; opening us to horrendous timing bugs.
However, in practice, because the Wine server often
handles requests within a single quanta, and because waiting
on a pipe with data gets a priority boost in Linux,
the net effect is what Wine wants.  (Thread A makes a request,
yields to the Wine server who gets in ahead of all other threads,
does the requests, sends the response back, and Thread A regains
control before any other Wine thread because it got a priority boost).

Second, the new 2.6  average time quanta of 100 ms is comparable
to the observed Windows quanta of 115 ms (I may have that wrong,
but I recall they were quite close), although the old, much
smaller time quanta masked a number of Wine scheduling problems.
But, in theory, having this longer time quanta should let us
better replicate Windows scheduling behavior.

However, we still have some issues.  First, the problem with
thread priorities still remains an issue.  A non zero number
of important applications rely on Windows priorities to
change timing behavior to make their applications run properly.
([editors note:  imho, these are poorly written apps, but
we have to support them as they are; wishing that MS would
rewrite PowerPoint to my spec is amongst the most futile things I can
imagine]).

There is a patch Mike worked up which makes a theoretical
improvement to the Wine server (pull requests from its queue
in thread priority order), but we have no evidence that
change makes any difference, and Mike backed away from it
when he found the afore mentioned 'correct' fix.
Nonetheless, I think it is conceptually 'right', so we probably
should bug Mike into redoing that patch.

I've played with a number of artificial ways to try to replicate
this within Wine, and have come up with a few compromises, but
nothing works perfectly (or, more importantly, worked up
nothing that Alexandre would apply <grin>).  If you do try to exactly mirror
Windows priorities, for example (running as root, say), you run
into issues where the wineserver gets starved and Wine stops
functioning.

Candidly, that's where I'm stuck.  I'm going to revisit a few
of my 'problem' apps hopefully sometime this year and see if I can
cobble together a hack that works best.  Ove, I haven't
tried the signalling approach; that seems like an interesting idea.

Sadly, short of asking the Linux guys to rewrite the Linux kernel
scheduler to exactly mimic Windows behavior, I'm not really
sure if there is a lot we can do to get this exactly right.

At any rate, that's the sum of what I learned this fall.  HTH.

Cheers,

Jeremy