[ros-dev] [ion] 20554: - Fix shamefully dangerously brokenWorkThread/Queue/Item implementation:

Ge van Geldorp gvg at reactos.org
Wed Jan 4 20:14:40 CET 2006


> 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



More information about the Ros-dev mailing list