On Mon, May 20, 2013 at 7:02 PM, Dmitry Timoshkov <dmi...@baikal.ru> wrote: > Qian Hong <qh...@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 - http://www.codeweavers.com
