More overlapped I/O issues (important)
mike_mccormack at start.com.au
Fri Nov 9 23:05:41 CST 2001
You're right, i never considered multiple overlapped requests at the
To fix the problem correctly, you will need to move (some of) the
overlapped code back to the wineserver, so that requests from
different processes can be handled correctly. (i moved it out of the
wineserver about a year ago for efficiency reasons.)
Have a look at rev 1.7 of server/async.c to see how this worked.
The current overlapped code (with the above exception) is similar to
what win 9x supports, so it does not support overlapped on normal
files, and file offsets in OVERLAPPED structures. If that could be
implemented too, it would be good.
i guess there is choice now... implement overlapped sockets with the
existing structure, or make a rather large change to the wine
architecture, which might take a while.
Maybe a good first step is to back out my change which put overlapped
operations into the client side code... Alexandre thought this could
be done using POLLIO instead...
Original message from: Martin Wilck <Martin.Wilck at fujitsu-siemens.com>
>Hi Mike, all,
>I see a severe problem with the current overlapped I/O
>especially wrt extending it to Winsock2 overlapped I/O.
>The problem I see is with buffer ordering.
>For normal files, the file position from which to read is on the
>OVERLAPPED struct. This was not in the Wine implementation, the patch
>my last email fixes it.
>For sockets and other FIFOs, this makes no sense. In this case
>specifies that buffers are read / written **in the same order they
>submitted**. This matters only if users spawn several asynchronous
>requests at the same time, but this is allowed and actually
>for application performance (at least on Windows).
>Unless I oversee something essential, the current wine implementation
>does not guarantee such behaviour. Actually, since new requests are
>inserted at the head of the NtCurrentTeb() list, they will be
>first in subsequent asynchronous reads - i.e. the order will be
>If I/O requests don't complete in a single read() or write() call,
>ordering will be basically random.
>IMO this implies that for sockets, asynchronous reads and writes must
>be scheduled such that only one request for a given socket is
>reading at a time, and all others are blocked until this request is
>finished. Again, this holds only for FIFO-type files.
>With the current structure, it seems to be very complex to sort this
>One could recheck the fd list in check_async and remove duplicate
>One could also try to "lock" the fd somehow. Still it would be
>to ascertain that the correct request gets the lock first.
>With this min mind, it seems more natural for me to organize the
>asynchronous requests in the "file" data structure itself. One would
>have a reader's and a writers's list there, and make sure that for
>only the first list element can actually issue a read(), write(),
>or recv() system call. For normal files all elements in the lists
>doing IO at the same time, question is if that makes sense or not.
>As I see it, this would mean both the readers and writers lists must
>be stored in the file data structure in the wine server.
>This would of course strongly affect the current implementation.
>Note that with Winsock2 overlapped I/O in place, it must
>be possible to use also ReadFile(), ReadFileEx() etc. on
>overlapped sockets, and get correct behaviour.
>Thus the ReadFile() etc. code must be able to deal with both sockets
>and ordinary files, and it makes no sense to intriduce a different
>approach for sockets only.
>Please give me your opinion on these issues ASAP.
>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
mailto:Mike_McCormack at start.com.au
ph +82 16 430 0425
Get your free Australian email account at http://www.Looksmart.com.au
More information about the wine-devel