Re: PendingReturned and a subsidiary IRP
- From: "David J. Craig" <Dave@xxxxxxxxxxxxx>
- Date: Sat, 25 Nov 2006 17:38:09 -0800
A subsidiary IRP belongs to the creator. Normally you will not allow the
IOManager to handle it when it shows back up in your completion routine. If
you use one of the functions other than IoAllocateIrp(), this rule does not
apply. If you use a block of memory to function as an IRP, you sure don't
want the IOManager to do final processing on it. You might do this if you
need an IRP when you are being called at an IRQL higher than PASSIVE_LEVEL.
Some drivers in the storage stack have this problem.
P.S. Do not use associated IRPs unless you are a FSD.
<BubbaGump> wrote in message
news:piphm2pn258dpbok19dvj1bkovuh41qpl0@xxxxxxxxxx
On Mon, 20 Nov 2006 17:00:07 -0500, BubbaGump <> wrote:
Right?
I should clarify something here.
I'm not asking if this is a common practice. I know it's not listed
in the current IRP-handling scenarios in Walt Oney's book or in MS
support, but while I was looking through the DDK samples one day I
noticed something interesting and surprising that got me thinking
about this. I saw a completion routine for an IRP that was sent
synchronously checking the PendingReturned not for what I'd thought
was its usual purpose of deciding whether to call IoMarkIrpPending for
an asynchronous IRP but instead for deciding whether to set the event
on which the routine that sent the IRP was waiting. It's a
performance optimization (although I'm guessing it's a small one).
Anyway, that's what made me curious. I wonder what other uses could
be invented for the PendingReturned flag, and this technique with a
subsidiary IRP is the first one that came to mind.
.
- Prev by Date: Re: DMA transfer speed issues on PCI card with PCI and PCI-X busses
- Next by Date: Re: IoTimer -- why polling?
- Previous by thread: Re: NT_SUCCESS propagation
- Next by thread: Will UMDF be ported to other platforms?
- Index(es):
Relevant Pages
|
