At 05:07 PM 8/12/2003 +1000, Nick Piggin wrote:
Mike Galbraith wrote:
Ah, but there is something there. Take the X and xmms's gl thread thingy I posted a while back. (X runs long enough to expire in the presence of a couple of low priority cpu hogs. gl thread, which is a mondo cpu hog, and normally runs and runs and runs at cpu hog priority, suddenly acquires extreme interactive priority, and X, which is normally sleepy suddenly becomes permanently runnable at cpu hog priority) The gl thread starts sleeping because X isn't getting enough cpu to be able to get it's work done and go to sleep. The gl thread isn't voluntarily sleeping, and X isn't voluntarily running.
The behavior change is forced upon both.
It does... It is I tell ya!
Look, the gl thread is probably _very_ explicitly asking to sleep. No I
don't know how X works, but I have an idea that select is generally used
as an event notification, right?
Oh, sure, it blocks because it asks for it... but not because it _wants_ to :) It wants to create work for X fast enough to make a nice stutter free bit of eye-candy.
Now the gl thread is essentially saying "wait until X finishes the work
I've given it, or I get some other event": ie. "put me to sleep until
this fd becomes readable".
Yes. Voluntary or involuntary is just a matter of point of view.
OK maybe your scenario is a big problem. Its not due to any imagined
semantics in the way things are sleeping. Its due to the scheduler.
It's due to the scheduler to a point... only in that it doesn't recognize the problem and correct it (that might be pretty hard to do). If my hardware were fast enough that X could get the work done in the allotted time, the problem wouldn't arise in the first place. I bet it's fairly hard to reproduce on a really fast box. It happens easily on my box because the combination of X and the gl thread need most of what my hardware has to offer.