4 Jan
2006
4 Jan
'06
7:14 p.m.
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