What's the value of non-read/write async handling?

NTFSD
1

Hi:

In looking at how various IRPs are handled, and wondering why it’s so
important to not block the calling thread by forcing synchronous handling.
Note: I’m not talking about read and write here.

For example, the Fastfat sources post a Close request to be handled
asynchronously (and returning STATUS_PENDING from the dispatch routine) by a
worker thread, which will complete the IRP. But why?

Reads and writes I understand, because the original user request can be made
to do async I/O. But why a close, or a cleanup, or any other request?
Returning STATUS_PENDING won’t cause the user thread to continue; the
CloseHandle() routine won’t return until the worker thread completes the
IRP.

What am I missing here?

Thanks,
Curt

2

> For example, the Fastfat sources post a Close request to be handled

asynchronously (and returning STATUS_PENDING from the dispatch
routine)
by a worker thread, which will complete the IRP. But why?

Look again. It completes the operation STATUS_SUCCESS; the
STATUS_PENDING is just coming back on the rare case we collide on the
resource with an async handle, or the case where we have a
supersede/overwrite above and don’t want to really do the operation (and
blow away the Fcb before the refcount goes back up). Since we delay
closes so frequently anyway, this costs little.

The cases are fairly well enumerated in FatCommonClose.

3

What’s the value of non-read/write async handling?Hi,

I believe that in the close case, this is done for purposes unrelated to the semantics of sync/async i/o. Close() may be invoked from within other dispatch routines (like from create() as a result of a CcFlushCache()). It seems that the fastfat code will return PENDING and queue the request to avoid deadlocks (as when Vcb->Resource cannot be acquired) or to avoid the FCB going away while in create().

Sara
Hi:

In looking at how various IRPs are handled, and wondering why it’s so important to not block the calling thread by forcing synchronous handling. Note: I’m not talking about read and write here.

For example, the Fastfat sources post a Close request to be handled asynchronously (and returning STATUS_PENDING from the dispatch routine) by a worker thread, which will complete the IRP. But why?

Reads and writes I understand, because the original user request can be made to do async I/O. But why a close, or a cleanup, or any other request? Returning STATUS_PENDING won’t cause the user thread to continue; the CloseHandle() routine won’t return until the worker thread completes the IRP.

What am I missing here?

Thanks,
Curt