Filip Navara wrote:
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.
Possible that is not correct. I see debug messages from read and write request at the same time. I see also that the written length from write request is shown as result for a read request. I've add a local overlapped structure in RPCRT4_Send. This does fix this problem. The test program shows now the correct result, but ros does crash at the end. There is a bug in KeRundownThread. If a mutant or mutex is on the threads mutant list, than ros does hang in a endless loop. If a mutant (user mode mutex) is on the list, ros does crash because 'ASSERT(Mutant->ApcDisable)' does fail.
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.
Your are right, the real problem is the using of the structure for twice.
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.
Yes, that's correct. We must check if there exist already a waiter and put the request on a list if any exist.
There is an other major bug in npfs. The fcbs have only one event. This works perfect for non duplex pipe. In duplex mode the read and write requests are using the same event.
- Hartmut