Robert Reif wrote:
Changes message queue from priority queue to standard queue.
this is wrong. If you've queued 10s worth of header, your reset request will have to wait 10s before being processed, which is not windows behavior. I'm also surprised if the headers (in case of a reset) are not send back to the app (this is what I see written in the code anyuway
It is not necessary and actually causes problems to put non header messages before header messages. Headers are queued within each thread. Sending some headers and then a reset will not work properly because the reset command will be placed at the head of the queue before the headers. It will then try to mark all headers done but there
won't be any because they are still in the queue.
I still don't get this... first the resetting message is gotten out of the queue in ProceedMessages, so I can't see how it can interfere (you said it's still in the queue) with the remaining headers
A+