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

[Mike McCormack]

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
>