RFC: How should ReadFile() on sockets behave ??

[Martin Wilck]

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