Is IRP asynchronous natively or should we handle it in that way?

NTDEV
1

Hello:

As the subject, does that mean even we write some blocking code in Dispatch routine, the user overlapped I/O request still doesn’t have to wait for our completeness, or it just say we have to implement our dispatch routine as asynchronous way, then user could gain this behavior?

Thanks
Nike

2

Hi!

     By default kernel operations are asynchronous and it is expressed to the User preocess depending on what behaviour the user process expects from the Kernel.

 

good luck

Still unmarried? Find a life partner now

3

Just because the user chooses to call the overlapped flavor of an API
like DeviceIoControl does not mean the system will force the API to
behave asynchronously (this would require it to shunt all such requests
to a worker thread before calling your driver). You need to design
asynchronous behavior into your dispatch routines by returning
STATUS_PENDING for requests that may take time to complete. For users
that invoke your dispatch routine via non-overlapped I/O, the system
will wait on their behalf for completion of the IRP. Those that choose
overlapped I/O, however, will be able to take full advantage of your
asynchronous behavior.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nike Chen
Sent: Sunday, March 23, 2003 6:42 PM
To: NT Developers Interest List
Subject: [ntdev] Is IRP asynchronous natively or should we handle it in
that way?

Hello:

As the subject, does that mean even we write some blocking code in
Dispatch routine, the user overlapped I/O request still doesn’t have to
wait for our completeness, or it just say we have to implement our
dispatch routine as asynchronous way, then user could gain this
behavior?

Thanks
Nike

You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

The second is right. Overlapped IO will degenerate to usual if the dispatch routine waits, with the only difference of still having the possibility of accessing the same handle from several threads without serialization.

Max

----- Original Message -----
From: Nike Chen
To: NT Developers Interest List
Sent: Monday, March 24, 2003 5:41 AM
Subject: [ntdev] Is IRP asynchronous natively or should we handle it in that way?

Hello:

As the subject, does that mean even we write some blocking code in Dispatch routine, the user overlapped I/O request still doesn’t have to wait for our completeness, or it just say we have to implement our dispatch routine as asynchronous way, then user could gain this behavior?

Thanks
Nike

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Your second idea is correct.

To put it the other way around – if you block in your dispatch routine
(say by calling KeWaitForSingleObject), your caller will not see
asynchronous (“overlapped”) behavior even if they’ve asked for it.

Driver writers are therefore very strongly encouraged to NOT block in
their dispatch routine, ever.

If you can’t complete the IRP or pass it to the next lower layer before
returning control to your caller, you should call IoMarkIrpPending, put
the IRP on a queue somewhere, and return STATUS_PENDING to your caller.
And you arrange for some other context, generally something you started
previously like a timer DPC or a DPC after your device interrupt, to
continue processing of the IRP you queued.

— Jamie Hanrahan
Azius Developer Training http://www.azius.com/
Windows Driver Consulting and Training

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nike Chen
Sent: Sunday, March 23, 2003 18:42
To: NT Developers Interest List
Subject: [ntdev] Is IRP asynchronous natively or should we
handle it in that way?

Hello:

As the subject, does that mean even we write some blocking
code in Dispatch routine, the user overlapped I/O request
still doesn’t have to wait for our completeness, or it just
say we have to implement our dispatch routine as asynchronous
way, then user could gain this behavior?

Thanks
Nike

You are currently subscribed to ntdev as: xxxxx@cmkrnl.com
To unsubscribe send a blank email to xxxxx@lists.osr.com