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 -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
