Originally posted by: bsobel
(I did notice that Explorer.exe, the default desktop shell, is set to "high"
If your suggesting this is the normal or default configuration, you are incorrect.
Bill
Really? That's... strange then. I assumed, that since the initial instance of Explorer.exe, forms the user shell, that MS intentionally set the priority for that instance higher, such that things like the taskbar (itself an Explorer.exe child window), would remain responsive in light of any potentially CPU-hogging processes, themselves operating at "normal" scheduling priority. Given that, a default setting of "high" for the user-shell instance of Explorer.exe, actually does make perfect sense.
Edit: An additional observation - right-clicking on the taskbar, and selecting "Task Manager", opens an instance of, well, Task Manager, and it is by default
also running at high priority. Think about it - if it wasn't running at a higher priority than any normal apps, then it would be competing for CPU resources with the very processes that the user was seeking to use that applet to control. Therefore, again, it makes sense that it should be set to running at a higher priority than the rest of the apps.
I was going to make a comment here about XP "feeling different" than W2K, when it came to differences in foreground/background scheduling priority, but then I found
this MS reference, which seems to indicate that it might just be a slightly different default setting, since it is configurable. I might play with that a bit.
Hmm,
this seems to support bsobel's assertion. I double-checked with Process Explorer, and indeed, it appears that the outmost (parent) Explorer.exe user shell, is the instance running at "normal", but the child instance is the one running at "high". I guess I made an erroneous observation based on the PIDs shown in Task Manager. (XP seems to re-use PIDs, and processes started later on in the session, can take low-valued PIDs, lower than "older" processes, and indeed, sometimes lower-valued than even system services/startup processes. I find that strangely confusing, compared to most monotonically-increasing OS PID models. But that's a different issue.)
Still, that doesn't make sense either, that
child Explorer.exe processes, would be running at "high" priority. No wonder shell DnD file-copy operations, cause burn-proof to kick in on my burner, because they automatically get a higher disk IO priority too.