26 Mar
2005
26 Mar
'05
10:28 a.m.
Hartmut Birr wrote:
Filip Navara wrote:
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)
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?
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