Driver has a sequential dispatching type read queue. Consider a scenario that driver is busy handling currently dispatched IO read request. Does WDF handles the timeout of IO read requests (overlapped IO operation by application) which are in IO read queue (not owned by driver)?
No. The only request related timeout WDF handles for you is for requests your driver sends to an io target.
Ok. Thanks. I have further question. Suppose application send two overlapped read requests in parallel and wait for 1 sec to finish. These requests shall be received in IO queue (seq queue) and shall be dispatched one by one to driver. Driver took 2 seconds to process one request. Mean time in application side, it get overlapped event timeout for these requests. What happened to these IO requests; one is in queue and another is owned by driver? Does IO Manager cancel one that in queue? What about one IO req owned by driver?
What happened âŚ
Nothing. Think about how this all works. When you say the application âwait for 1 sec to finishâ, that means the application called WaitForMultipleObjects with a 1 second timeout. Thatâs going to return WAIT_TIMEOUT. That doesnât say ANYTHING about the individual events. It just means the timeout expired before any of the requests completed. The requests are still outstanding, and the application still has to worry about handling them. Usually, the app will just call WaitForMultipleObjects again. Eventually, the requests will complete, either successfully or with a cancellation or a timeout. The application still has to call GetOverlappedResult for the requests that completed.
Does IO Manager cancel one that in queue?
IO Manager doesnât know anything about queues. Cancellation is handled by the driver. When a request in on a WDFQUEUE, cancellation is handled by the KMDF code, which is part of the driver.
Also note that there is no such thing as a ârequest timeoutâ from user mode, and you canât cancel individual requests. When the application gets WAIT_TIMEOUT from WaitForMultipleObjects, it certainly has the right to call CancelIo to cancel all requests on the file handle. That sets the âcancelâ bit in the IRP, and the driver is supposed to respond by completing the requests with STATUS_CANCELED.
What about one IO req owned by driver?
Itâs the same, except that KMDF isnât going to handle the cancellation automatically. The driver has to check for it and respond.
âCancellationâ in Windows is really just a suggestion. When an IRP is canceled, that sets a bit in the IRP. Thatâs it. It is entirely up to drivers to figure out how and when to check for that bit, and then complete the request with STATUS_CANCELED. Itâs not automatic.
Itâs not just Windows where cancel is a âsuggestionâ. Any system at any scale where async operations are issues and can later be cancelled must implement cancel this way. think about it, the call to cancel may occur after the request has been sucessfully processed - just before the caller becomes aware of it
Thanks alot for reply.