Hi Martin,
You're right, i never considered multiple overlapped requests at the same time...
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.
http://cvs.winehq.com/cvsweb/wine/server/async.c?rev=1.7&content-type= text/x-cvsweb-markup
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...
Mike
Original message from: Martin Wilck Martin.Wilck@fujitsu-siemens.com
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.
Regards Martin
-- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425
__________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au