Hartmut Birr wrote:
Filip Navara wrote:
I think that is a bug in the rpcrt4 implementation. The receive and send functions do check for a pending io request in a wrong way.
It's not impossible, but the code works just fine on Windows and Wine... Can you point me to the code you think is wrong?
rpc_message calls ReadFile/WriteFile for pipes which are open for asynchronous requests. ReadFile/WriteFile can fail for an pending request. If it fails, the caller must check the last status (GetLastError()) for ERROR_IO_PENDING.
The attached patch addresses this issue... (but it doesn't seem to help the test program)
An other problem is the using of the overlapped structure. The same structure is used for read and write requests. Sometimes the results from a write request is interpreted as a result from a read request.
All the read and write operatrions are de facto synchronous because they're always followed by GetOverlappedResult with Wait == TRUE, so this should never happen.
It is also a bug in GetOverlappedResult. GetOverlappedResult must always check if the event is signaled. The status value may contain the result from the previous request.
The status value is initialized in the ReadFile / WriteFile calls, so again, this shouldn't be problem.
Another thing I'm afraid of are race conditions in your asynchronous read code in NPFS. I believe that you can get the reads out of order in certain conditions... Imagine this:
Process 1: Async. ReadFile -> No data available -> PENDING Process 2: WriteFile -> Fills the internal buffers and sets the event Process 1: Async. ReadFile <- Here the request can be satisfied before the worker thread realizes that there are new data and completes the PENDING request.
Does it make sense?
Regards, Filip