• Re: OVERLAPPED ReadFile() doesn't overlap

    From KP2 KP2@21:1/5 to Jim Beveridge on Sun Nov 19 18:03:37 2023
    On Tuesday, December 23, 1997 at 12:00:00 AM UTC-8, Jim Beveridge wrote:
    I was very interested to read through this thread. I encountered the sync/async ReadFile() problem 18 months ago when I was researching my book, "Multithreading Applications in Win32." I spent many days on the phone with Microsoft support (how many times CAN you be escalated??), who finally concluded that what is being described in this newsgroup thread is just the way it is.
    If you do a search on MSDN on FILE_FLAG_NO_BUFFERING, one of the titles
    that comes up in the knowledge base is, "SAMPLE: Asynchronous Disk I/O on
    NT Appears as Synchronous". This article was written as a direct result of
    my time spent on the phone with tech support. Unfortunately, the article merely describes the observations, it doesn't go into any depth on the reason.
    Since I wrote the book, I have talked to Lou Perazolli (sp?), but I wasn't able to get a good answer for what was happening. The discussion by Felix
    was the first attempt I have seen that provides a reasonable explanation of what the internals are doing.
    The reason I originally dove into the problem was I was trying to show that overlapped I/O could be used to allow a single thread to efficiently serve
    a large number or users as long as the processing requirements on the
    server were minimal. Because of the sync/async problems, the sample was a total failure and I had to scrap it.
    Thanks to everyone involved for an interesting discussion.
    Jim Beveridge
    Author of "Multithreading Applications in Win32"

    Don Lee <dl...@esd.dl.nec.com> wrote in article <3489DA05...@esd.dl.nec.com>...


    Benjamin Kaufman wrote:

    Don,

    Take a look at the description of ReadFile. In particular,

    "...If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is
    not NULL, the read operation starts at the offset specified in the OVERLAPPED structure and ReadFile may return before the read operation has been completed..."

    The key here is the word MAY. Since you are reading a sequential, buffered file the driver "thinks" that it would be faster to do it this way than go through the overhead of an event notification. Since your total latency was 4 ms, I would tend to agree with the driver.

    g

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)