Hi Mike,
Hmmm. MSDN says that FD_READ is only re-enabled on recv, recvfrom, WSARecv and WSARecvFrom. Maybe you should verify that ReadFile doesn't re-enable FD_READ on a windows platform or two?
You're absolutely right. Unfortunately this will take some time. The problem is that FD_READ has some really awkward connection with FD_CLOSE events, pretty hard to explain shortly. The discussion I had with Ove lately ("Urgent need for advice...") may give you some insight.
ReadFile in asynchronous mode already reports completion of reads to the wineserver...
Are you talking about finish_async() ?
why not make it always work like FILE_TimeoutRead in files/file.c for sockets?
I have been thinking about that, but it means adding some overhead for non-overlapped operations (doing an overlapped request this way requires more than just one server call).
This hardly matters for slow comm ports, but it may matter if you communicate over a Gbit ethernet network socket.
I like the idea, though, of getting rid of the distinction between overlapped and non-overlapped IO by just making everything overlapped and immediately waiting for the results in the synchronous case. (Basically the same code we're already using now in order to check if an overlapped operation can be completed immediately, just with bWait=TRUE).
It would also have the benefit that you could mix asynchronous and synchronous calls to an overlapped fd without corrupting your data (I don't know if there are apps out there which do that, nor what Windows would do - the ReadFile() docs forbid it, but the WSARecv() docs don't).
Of course this would also mean that all server objects that can be addressed with ReadFile() and WriteFile() must support asynchronous IO (wine-internally).
I'll wait for other people's opinions.
Martin