[ros-dev] RE: [ion] 20554: - Fix shamefully dangerously broken WorkThread/Queue/Item implementation:

[Alex Ionescu]

Ge van Geldorp wrote:

>I haven't looked at your code yet, but the comment worries me. Does it mean
>that if a usermode app is stuck in a "while (1) ;" loop stuff queued by
>IoAllocateWorkItem( ) never gets executed? If I misunderstood, nevermind,
>disregard this message. If this is true we're in big trouble. We're using
>work items in a lot of places to get from DPC level to PASSIVE level. For
>example, the networking stack queues a work item when data was received from
>the network card. I'd hate to see a stuck usermode app halt all network
>communications...
>
>GvG
>
>  
>
Hi,

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.

Best regards,
Alex Ionescu