I just recently experimented with Cancel-Safe Queue's and wonder how
practical it is to use them for IRP's I've created using IoAllocateIrp()
and IoBuildDeviceIoControlRequest().

Am I out-of-line here?

Thanks,
Bob

Robert Stankey wrote:
Why would you want to queue an IRP you've created? If you're not ready
to send it down to somebody to do something, why not just wait until you
ARE ready? If you're thinking that you want to create a pool of IRPs
that you can send down the stack, is there a good reason why you don't
either (a) wait until you're ready to send a request down to call
IoAllocateIrp, or (b) recycle IRPs from a pool from inside a completion
routine?

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

On Thu, 23 Sep 2004 13:23:53 -0400, Walter Oney wrote:

Hi Walter,

I'm seeing a condition where one of my devices receives an
IRP_MN_REMOVE_DEVICE request so I wait until the remove lock count reaches
zero. Well, it never does because one of the Irp's I've created has not
completed. I thought I could keep track of the Irp's I've created and sent
to various devices, and if I recieve a IRP_MN_REMOVE_DEVICE request go
through my list and cancel those going to that device. The requests are
synchronous with no timeout.

Note this particular issue doesn't always happen during a removal. Is it
possible there's a problem with another driver instead of mine?

Bob

Robert Stankey wrote:
Okay. Practically any queuing scheme is going to use fields in the IRP
that belong to whoever owns the IRP. That will be the driver at the
bottom of the stack that's holding onto the IRP waiting to do something
with it. You therefore can't use CSQ or any other common queuing scheme.

To safely cancel an IRP in this situation, you need to use a technique
like the one I describe in ch. 5 of my book. That involves a PIRP and a
LONG in your device extension that you use in a particular sequence to
avoid various race conditions.

Very likely. I think a driver (such as the one you sent the IRP to) has
an obligation to cancel any queued or in-process IRPs when it gets a
SURPRISE_REMOVAL notification. However, you may need to keep track of
IRPs you send down the PnP stack in order to cancel them when you get a
QUERY_POWER request. IIRC, the USB stack will fail the query if an IRP
is active. This is one reason why programming an interrupt endpoint is
such a huge pain.

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

On Thu, 23 Sep 2004 22:43:54 -0400, Walter Oney wrote:

I have the 1st edition of your book (very good BTW) so I'll go back and
re-read that chapter. I'd like to avoid any extra overhead if possible
(more opportunity for things to go wrong).

Bob

Robert Stankey wrote:
There are three reasons why you should get the 2d edition. It has many
errors fixed (including some in the very area you're interested in), it
contributes $2.00 to the Walt & Marty Oney retirement fund, and it and
the 1st edition together make a good dining-room-chair extender for a
growing family.

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com