Why not a strait forward approach. [LWN.net]

Why not a strait forward approach.

Posted Mar 18, 2007 19:41 UTC (Sun) by aashenfe (subscriber, #12212)
In reply to: Why not a strait forward approach. by nlucas
Parent article: RSDL hits a snag

So then what would really need to happen is X or a sound daemon would somehow need to give some of it's priority to processes they interact with. These programs would either have to consciously be written to do this, or some kind of heuristic would be used.

It is a little easier for Windows, but I'm not sure if giving a priority boost to the foreground window application is always the best.

(Log in to post comments)

Why not a strait forward approach.

Posted Mar 18, 2007 20:41 UTC (Sun) by nlucas (subscriber, #33793) [Link]

It is a little easier for Windows, but I'm not sure if giving a priority boost to the foreground window application is always the best.

I was over-simplifying, off course.
On windows each process has a single base priority, but each thread has a priority (based on the process priority) that can be boosted for short periods (and with limited range).
Also, there is a distinction between system and local processes. The system ones have a base priority sligthly higher than local ones, and if a wait is not satisfied for a thread, it's quantum is reduced (they call it quantum decay).
This foreground window boost for all threads that own that window is made for interactivity sake, but can be disabled when you configure Windows to optimize performance for background services (and is the default on the server versions).

I'm no scheduling master, I just happen to have read the "Windows Internals" book by Mark Russinovich and David Solomon. There are differences between Windows versions, so if you really want to learn more (and not only about this) I would advise you to get that book.