4 Jan
2006
4 Jan
'06
8:26 p.m.
Ge van Geldorp wrote:
I will re-verify this...
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)
Huh? Where are you getting this information from? I'm not denying it but
I have received no warning that I've caused such a regression, unless
this is it? :)
, although fixing the regression (bug 1213)
caused by your previous commits might take some of your time too.
Sorry, again, what does 1213 have to do with me? I received no
information relating to this bug... I will look at the bug report now..
Next time I apparently cause regressions, please add me to the CC list
of the bug so I can know what regressions I may or may not have caused.
GvG
Best regards,
Alex Ionescu