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