Hi Mike,
I just had the following thought on the immediate IO in ReadFile() / WriteFile() that you implemented:
Consider the following situation:
1. There is no data available for reading on some fd (serial port, pipe, socket). 2. An application calls ReadFile() in overlapped mode. since no data is there, an overlapped request is scheduled. 3. Data becomes available before the app issues a wait request of any kind. 4. The application starts another ReadFile() request. Now data is there, and will be read immediately. No async request is scheduled. 5. Eventually, more data will become available, and the async request first scheduled will also return.
However, this basically destroys the order of the requests. I am unsure how Windows would behave in such a case, and it is certainly difficult to provide a test case for this situation. It can occur, though, and my guess is this is the wrong behaviour.
Thus, probably before doing the immediate read it should be checked if there are asynchronous requests already scheduled for reading, and if yes, ReadFile() should _not_ try to read immediately but go pending. Of course, this check would require a server call.
The same reasoning applies for writing, of course.
Things become even more confusing if you think of several threads reading from the same file.
A very simple workaround would be to go pending unconditonally for overlapped requests. Although not optimal, this would be certain not to corrupt data.
What do you think?
Martin
What about the following idea:
Instead of doing an explicit immediate IO operation in e.g. ReadFile(), que an asynchronous request by calling ReadFileEx() as if no data were available. Then issue a
WaitForSingleObject (overlapped->hEvent, 0) /* zero timeout ! */
to see if the request can be handled immediately. Apart from preserving request order, this would also ensure that previous async requests are actually scheduled.
Opinions?
Martin
-
Martin Wilck