Re: More overlapped I/O issues (important)

[Mike McCormack]

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
> 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: [phone]
> Fujitsu Siemens Computers   Fax:   [phone]
> Heinz-Nixdorf-Ring 1	    mailto:[e-mail]
> D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

------------------------------------------
mailto:[e-mail]
ph [phone]

__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au

More overlapped I/O issues (important)

[Martin Wilck]

On Sat, 10 Nov 2001, Mike McCormack wrote:
> 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.

In the patch I submitted, the pread() calls will fail on FIFOS, and
a normal read will be issued instead - so both should be fine (needs
testing, though).
> 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.

I am convinced  that multiple simultaneous async read/writes need to
be supported. Moreover, the ReadFile()/WriteFile() calls need to
work on sockets, therefore two separate implementations are out
of the question.

Of course the goal should be to make this work using as much of the
existing code as possible.

Regards,
Martin