On Mon, May 20, 2013 at 7:02 PM, Dmitry Timoshkov dmitry@baikal.ru wrote:
Qian Hong qhong@codeweavers.com wrote:
MSDN page you referenced has a hint how this behaviour could be tested:
"The WSAAsyncSelect or WSAEventSelect routine automatically sets a socket to non-blocking mode. If WSAAsyncSelect or WSAEventSelect has been issued on a socket, then any attempt to use WSAIoctl to set the socket back to blocking mode will fail with WSAEINVAL. To set the socket back to blocking mode, an application must first disable WSAAsyncSelect by calling WSAAsyncSelect with the lEvent parameter equal to zero, or disable WSAEventSelect by calling WSAEventSelect with the lNetworkEvents parameter equal to zero."
Thanks for advice, I noticed that method and I though it is not ideal since it is an indirect test rather than a direct test.
The above description implies two behaviors: A: 'The WSAAsyncSelect or WSAEventSelect routine automatically sets a socket to non-blocking mode' B: 'any attempt to use WSAIoctl to set the socket back to blocking mode will fail with WSAEINVAL'
Currently Wine's winsock implementation already respects the behavior B, but doesn't respect the behavior A. I can add a test to proof behavior B, is that enough?
Thanks again!
-- Regards, Qian Hong