If there is a socket for which event notification has been requested by the application with WSAEventSelect(), the behaviour is as follows:
- When data arrives, FD_READ is signalled _ONCE_. - FD_READ is only delivered again if the app explicitly reenables it with WSAEventSelect/WSAAsyncSelect or if the application issues a recv() call. - The latter is accomplished in wine by calling _enable_event ( FD_READ, ...) after every recv() operation in the winsock code. - If an app uses ReadFile() rather than a winsock call to retrieve data, the FD_READ event is of course not reenabled, because the current implementation in file.c has no concept of socket events.
Question: should ReadFile() behave like recv(), i.e. reenable FD_READ, or not? If yes, we would have a certain dependency of the ReadFile() code on winsock, because FD_READ etc are winsock-specific macros. If no, an app that relies on ReadFile() reenabling FD_READ will obviously fail.
The best thing would probably be to do this in the server, but we currently can't, because the server does not notice when a read operation is finished.
Opinions? Martin
Hi Martin,
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?
ReadFile in asynchronous mode already reports completion of reads to the wineserver... why not make it always work like FILE_TimeoutRead in files/file.c for sockets?
Mike
Martin Wilck wrote:
If there is a socket for which event notification has been requested by the application with WSAEventSelect(), the behaviour is as follows:
- When data arrives, FD_READ is signalled _ONCE_.
- FD_READ is only delivered again if the app explicitly reenables it with WSAEventSelect/WSAAsyncSelect or if the application issues a recv() call.
- The latter is accomplished in wine by calling _enable_event ( FD_READ, ...) after every recv() operation in the winsock code.
- If an app uses ReadFile() rather than a winsock call to retrieve data, the FD_READ event is of course not reenabled, because the current implementation in file.c has no concept of socket events.
Question: should ReadFile() behave like recv(), i.e. reenable FD_READ, or not? If yes, we would have a certain dependency of the ReadFile() code on winsock, because FD_READ etc are winsock-specific macros. If no, an app that relies on ReadFile() reenabling FD_READ will obviously fail.
The best thing would probably be to do this in the server, but we currently can't, because the server does not notice when a read operation is finished.
Opinions? Martin
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
-
Martin Wilck -
Mike McCormack