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

[Jeremy White]

> 
> Well the scheduler is not going to be rewritten any time soon (trust me, 
> I've tried :P). Tell me what remaining requirements your threads have 
> that you are unable to achieve at the moment and I'll see if I can help 
> with my understanding of the priority system as it is, in a generic way 
> that hopefully will work across scheduler designs.

What!?!?!  The Linux Kernel schedulor won't be rewritten to the exact
demands of Wine!  Shocking! <grin>

At this point, I think the only glaring hole we have is the issue of
thread priorities.  That seems to be a capability we simply can't
accurately replicate in Wine.  My hope is that if we can somehow
mock that up (or address the few dodgy cases where it's a problem),
we won't face any other timing issues.

 From there, I think the honest truth is that I have more homework to do;
we tend to take the pragmatic approach that a theoretical problem is
uninteresting until we have real apps with real unsolvable problems.
So I need to go find some more problem cases and understand them.

In the interest of making this thread complete, I wanted to add
a concern or two I forgot, and to belabor a point or two
(that's your clue to tune out now, folks <grin>).

Specifically, there are other areas of interest when you think about
timing and scheduling.  First is the Windows very clear cut 'foreground
window' boost.  I have no idea how this maps into the Linux
interactivity strategy.  They seem to be roughly equivalent, and I
never found an application that relied on that timing.

Second, the exact sequence of when a thread
yields or not on Windows is not something I'm sure I fully learned; I did
my best, but my gut tells me that I must have missed some cases.
The main trick as we make sys calls here is to make sure that we don't accidentally
yield at times when Windows wouldn't.

That connects to the theoretical flaw in Wine (the whole use of the
Wine server) that should make us vulnerable to all sorts of
unexpected context switches, creating timing patterns unfamiliar
to Windows applications, and causing problems.  And yet,
from observation, I never see any such unexpected context switches.
The Linux kernel priority boost for pipes seems to protect us here;
we should make sure we understand why and let the kernel guys know that
we depend on it, so they don't knock it out from under us some day.

Fourth, based on your reply to my earlier email, I suspect I do
not understand how time quanta are assigned.  In fact, I had come to
some conclusions at one point last fall, that I can no longer
convince myself of (I was persuaded that a thread that constantly
yielded had it's time quanta dranstically reduced; I can no longer
reproduce that).  Further, time quanta differences can be crippling to Wine.
Photoshop, for example, relies on reliable 5ms timing, and if it doesn't
get it, it doesn't work.  Similarly, I could swear I had a problem
case in IE where two threads were interdependent, and the one thread
never got a large enough quanta to keep the second thread happy (and
this then caused a spiral that led to the small quanta for thread A).
Sadly, I didn't take good notes, so I have to go back and relearn that case
again.  And, knowing me, I probably completely misunderstood it anyways :-/.

Sorry to ramble on; it's just tough around here, because everyone
is tired of hearing me claim that every bug is a timing problem... <grin>

Cheers,

Jeremy