ZwCloseHandle asynchronous on no read/write activity?

Discussion in 'Windows Vista Drivers' started by dmitry.sychov, Oct 1, 2006.

  1. Greetings,

    I assume ZwCloseHandle is optimized in such a way that is always
    returns
    immediately, then doing the close asynchronously.

    [ of course it is not true if there is running overlapped io over file
    handle - this fn
    waits for its completion then, but thats ok ]

    But what if all read/write jobs are reported to be completed - could
    ZwCloseHandle still
    initiate i/o request like synchronous file attributes write and most
    importantly block in it
    waiting for its completion, or updating file metadata will be always
    performed asynchronously?

    I'am asking this since for me any unpredicted delay is unacceptable -
    i'd better always run the
    close via separate thread - this is generally slower but at least i can
    be sure the thread will not block.

    host platform is win xp+

    file system could be FAT(hope it does not matter)

    thank you

    dmitry
     
    dmitry.sychov, Oct 1, 2006
    #1
    1. Advertisements

  2. why is the perf of closing a handle an issue? are you doing it in a perf
    critical path? if so, why are you tearing down resources in a performance
    critical path to begin with?

    d
     
    Doron Holan [MS], Oct 1, 2006
    #2
    1. Advertisements

  3. Hi,
    because the load is not constant and could be high

    i do not want for thread to wait for close op to flush metadata
    while i can do some purely cpu-based tasks
    there are certain loads when all paths become perf critical :)
    why me? ts not me, but the users...

    regards, dmitry
     
    dmitry.sychov, Oct 1, 2006
    #3
  4. close handle is synchronous. it sends a cleanup and possibly a close irp to
    the FS. what the FS does with that is dependent on the FS. i think you are
    micro optimizing one call, you can't fully peg the CPU in all paths ;)

    d
     
    Doron Holan [MS], Oct 2, 2006
    #4
  5. I think the FS should queue the request, ie internally delay the
    actual processing of the close/cleanup IRP even with STATUS_SUCCESS
    return.

    and "delete-on-close" should be delayed too.

    I believe this is both true for NTFS & FAT.

    but this should be properly documented like it is done for other OSes.
    why not, it does not take much time anyway. :)

    regards, dmitry
     
    dmitry.sychov, Oct 2, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.