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 >
