Does WDF manages timeout of IO request which is not owned by Driver

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.

1 Like

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.

1 Like

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

1 Like

Thanks alot for reply.