From: Alex Ionescu
I've simply made work threads have the same priorities as in NT, so now they act the same (that is, lower priority then normal threads). I'm not quite sure how the scheduler in ReactOS handles your scenario however; while it is true that when an app is stuck and its thread's quantum runs out, the NT scheduler will prefer to choose a thread with a higher priority; however, after a while, the threads with lower priority will have been in a wait state for a long time, the kernel will realize this, boost their priorities and have them run again.
AFAIK (but this is certainly not my area of expertise) we don't boost priorities. But even if we did, it's not good enough since it takes too long for the work items to be run. Having a single network packet come in every tenth of a second or so doesn't sound too appealing.
Your change doesn't seem consistent with MSDN, my CD copy of Oct-2005 (can't find it in the online version) documents a WORK_QUEUE_TYPE CriticalWorkQueue as "Insert the WorkItem into the queue from which a system thread with a real-time priority attribute will process the work item." Of course, MSDN has been known to be wrong before.
Anyway, you still have a couple of weeks before the next release to fix the regression you introduced (affecting at least networking, Tab+K behaviour, I think mouse message delivery), although fixing the regression (bug 1213) caused by your previous commits might take some of your time too.
GvG