ReadFile and WriteFile in overlapped mode

[Martin Wilck]

Hi Jaques,

Please try the following patches and see if they change the results you
see:

http://www.winehq.com/hypermail/wine-patches/2002/04/0020.html
http://www.winehq.com/hypermail/wine-patches/2002/04/0021.html

(the second one is the relevant one in this context, but it requires the
other to be applied first).

Apart from that, I have a few remarks on your posting:

> I have been looking at those two functions and some specs. My understanding
> is that those function do not work at all in overlapped (async mode).

I have done a fair bit of testing on these very recently and think they do
work. On what sort of file (regular, serial port, pipe, ...) are you
reading/writing ?

> Currently (latest stuff in CVS), both function handle overlap mode like this

This has been so for quite a while.

> a)	Give it a try in synchronous mode using a combination
> 	of pread/read and pwrite/write.
>
> b)	If not enough bytes were read or written, a request
> 	is sent to wineserver to perform and asynchronous
> 	operation. This request always fail. (don't know why yet).

What do you mean by "fail" ?

> There is two problem here. If step a succeed, no event will ever be
> generated since step be is not performed. Application doing the following
> sequence

That's right. This is what the MSDN specs say:

<quote from ReadFile specs>
If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL,
the read operation starts at the offset specified in the OVERLAPPED structure
and ReadFile may return before the read operation has been completed.
In this case, ReadFile returns FALSE and the GetLastError function
returns ERROR_IO_PENDING. This allows the calling process to continue while the
read operation finishes. The event specified in the OVERLAPPED structure
is set to the signaled state upon completion of the read operation.
</quote>

The function may, but doesn't have to, return before the operation
completes. Whether the event is signaled upon immediate completion is
unclear. But then, compare the GetOverlappedResult spec:

<quote from GetOverlappedResult spec>
The results reported by the GetOverlappedResult function are those of the specified
handle's last overlapped operation to which the specified OVERLAPPED structure was
provided, -->and for which the operation's results were pending<--.
A pending operation is indicated when the function that started the operation returns
FALSE, and the GetLastError function returns ERROR_IO_PENDING. When an I/O operation is pending,
the function that started the operation resets the hEvent member of the OVERLAPPED
structure to the nonsignaled state. Then when the pending operation has been completed,
the system sets the event object to the signaled state.
</quote>

(-->arrows inserted by me<--).

This is a bit clearer and indicates that the following code you quote:

> 	ReadFile
> 	..
> 	WaitOnSingleObject

is wrong unless the return state and error code of ReadFile() are checked
between the two statements - WaitForSingleObject() should only be called
if ReadFile fails with ERROR_IO_PENDING.

> My understanding is that step a should never be done and only step b.
> Is that correct ?

No, but see the patches above - things can be done differently.

> Now, why step b is failing is another story.

Indeed, that should be further investigated.

Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck at Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy