[ros-dev] Re: [ros-svn] [hbirr] 14296: - Guarded the calls to IoSetCancelRoutine with IoAcquireCancelSpinLock/IoReleaseCancelSpinLock.

[Filip Navara]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpcrt.diff
Type: text/x-patch
Size: 3755 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-dev/attachments/20050326/aa3ea0dc/rpcrt.bin