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