More overlapped I/O issues (important)

Martin Wilck Martin.Wilck at
Fri Nov 9 14:23:33 CST 2001

Hi Mike, all,

I see a severe problem with the current overlapped I/O implementation,
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 in
my last email fixes it.

For sockets and other FIFOs, this makes no sense. In this case Windows
specifies that buffers are read / written **in the same order they were
submitted**. This matters only if users spawn several asynchronous I/O
requests at the same time, but this is allowed and actually beneficial
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 considered
first in subsequent asynchronous reads - i.e. the order will be reversed.
If I/O requests don't complete in a single read() or write() call, the
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 actually
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 out.
One could recheck the fd list in check_async and remove duplicate fds.
One could also try to "lock" the fd somehow. Still it would be necessary
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 FIFOS
only the first list element can actually issue a read(), write(), send(),
or recv() system call. For normal files all elements in the lists could be
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
D-33106 Paderborn 

More information about the wine-devel mailing list