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). Currently (latest stuff in CVS), both function handle overlap mode like this
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).
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
ReadFile .. WaitOnSingleObject
will wait forever. Some borland Builder classes do this
My understanding is that step a should never be done and only step b. Is that correct ?
Now, why step b is failing is another story.
Comments ?
--------------------------------------------------------- Jacques Gelinas jack@solucorp.qc.ca vserver: run general purpose virtual servers on one box, full speed! http://www.solucorp.qc.ca/miscprj/s_context.hc
On Fri, 05 Apr 2002 06:01, Jacques Gelinas wrote:
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). Currently (latest stuff in CVS), both function handle overlap mode like this
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).
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
ReadFile .. WaitOnSingleObject
will wait forever. Some borland Builder classes do this
My understanding is that step a should never be done and only step b. Is that correct ?
Now, why step b is failing is another story.
I fixed this a while ago, but never finished submitting the patch. The problem is that wine uses async callbacks to signal the event in the overlapped structure, which is a problem, because async callbacks can only happen when WaitOnSingleObjectEx specifically allows them. The solution is to have the wine directly trigger the event without going through the async callback system.
On Fri, 5 Apr 2002, Tony Bryant wrote:
I fixed this a while ago, but never finished submitting the patch. The problem is that wine uses async callbacks to signal the event in the overlapped structure, which is a problem, because async callbacks can only happen when WaitOnSingleObjectEx specifically allows them.
This is not correct. The async IO requests are system APCs which are called if the wait status is SELECT_INTERRUPTIBLE, which is always the case with WaitForMultipleObjectsEx() and related functions (see server/thread.c and scheduler/synchro.c).
Only the "Completion function" for ReadFileEx() and friends needs an alertable wait, which is perfectly in accord with the MS specs.
The solution is to have the wine directly trigger the event without going through the async callback system.
I think the current code does things right.
If you look at the MSDN specs for GetOverlappedResult(), it says clearly that you can only rely on event notification if the function that created the request (e.g. ReadFile() returned FALSE with error code ERROR_IO_PENDING. The current implemengtation does set the event when the async IO is finished, and no sooner.
Martin
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
-
Jacques Gelinas -
Martin Wilck -
Tony Bryant