Hi All, I need to increment the ref count on wdf request in cancellation routine. Once the reference count is incremented, I would queue a work item and pass this wdf request to it. In workitem I would check if the request is still pending with hardware if so then I cancel the request else if the request is completed/cancelled I just decrement the reference count and return. How can I increment the reference count on wdfrequest ? Thanks Aj
WdfObjectReference will keep the object alive until dereferenced but does not protect the object’s state.
Right. Remember that the IRP that is being wrapped by the WDFREQUEST goes invalid once the request is completed, and KMDF can’t prevent that. What are you planning to do that needs this?
Hi Tim,
Thanks for your response.
Here is what I am planning to do.
-
I have setup a extension part in each WDF request (RequestExtension). This extension part holds some state about the request.
-
When I get a cancel routine, I am planning to increment the ref count on the WDF request and schedule a WorkItem.
-
In the workitem which is at passive level, I am reclaiming the commands from the hardware and completing (cancelling) them to the OS. This abort is really a hammer and would like to perform this abort only when the hardware is not responsive.
-
When I receive the wdfrequest in the workitem, I look at the extension part of the request and see if the request gets completed or not. If the request gets completed I avoid the abort hardware operations. If the request does not get completed, I perform the abort. The only thing I need is the extension part of the WDFREQUEST. I do not not modify the wdfrequest in anyway and I just access the extension part.
Any thoughts are appreciated.
-Thanks
Aj.
You don’t need a reference count for this, do you? Don’t you just need a COUNTER that you decrement in each location where you could ultimately complete the Request, and when this counter goes to zero that’s when you complete the Request?
That’s the classic way of handling cancel in WDF. Or, at least, the classic way I handle cancel in WDF
Peter
@“Peter_Viscarola_(OSR)”
But where does that counter reside? the logical place is the request extension, then I will have to make sure that the request extension lives long enough so that I can access it in my abort. There is a delay between when the Cancel is called and my abort gets called. in that time the request could be completed and then the extension part will get destroyed. Instead of a counter I have a state but that does not really matter. I need to keep my extension alive.