Re: [PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.

[Dmitry Timoshkov]

Qian Hong  wrote:
> Fixed http://bugs.winehq.org/show_bug.cgi?id=33076
>
> Reference: 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms741621%28v=vs.85%2...
>
> See also comment in WSAIoctl:
> /* AsyncSelect()'ed sockets are always nonblocking */

This change requires a test case, MSDN is often wrong, so its claims
at least need to be very carefully checked.

[PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.

[Qian Hong]

Hi Dmitry,

On Mon, May 20, 2013 at 6:13 PM, Dmitry Timoshkov  wrote:
> This change requires a test case, MSDN is often wrong, so its claims
> at least need to be very carefully checked.

Thanks for the comment, actually I already guess you will point out it
requires a test :)

There is no win32 api to detect whether a socket is blocking or
non-blocking, do you have any advice how to test it in our Wine test
framework?

Thanks a lot, as always!

--
Regards,
Qian Hong

-
http://www.codeweavers.com

[PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.

[Dmitry Timoshkov]

Qian Hong  wrote:
> Thanks for the comment, actually I already guess you will point out it
> requires a test :)
>
> There is no win32 api to detect whether a socket is blocking or
> non-blocking, do you have any advice how to test it in our Wine test
> framework?

http://stackoverflow.com/questions/5489562/in-win32-is-there-a-way-to-test-i...
seems to confirm that.

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."

[PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.

[Qian Hong]

On Mon, May 20, 2013 at 7:02 PM, Dmitry Timoshkov  wrote:
> Qian Hong  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

[PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.

[Dmitry Timoshkov]

Qian Hong  wrote:
> 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?

I'd test it like the following:

1. create a socket
2. check that WSAIoctl works
3. call WSAAsyncSelect/WSAEventSelect
4. check that WSAIoctl fails
5. set the socket back to blocking mode using described technique
6. check that WSAIoctl works

of course checking for exact error codes and such.

[PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.

[Qian Hong]

On Mon, May 20, 2013 at 7:53 PM, Dmitry Timoshkov  wrote:
> I'd test it like the following:
> - create a socket
> - check that WSAIoctl works
> - call WSAAsyncSelect/WSAEventSelect
> - check that WSAIoctl fails
> - set the socket back to blocking mode using described technique
> - check that WSAIoctl works
>
> of course checking for exact error codes and such.

Ok, will send a test patch, thanks for advice!

--
Regards,
Qian Hong

-
http://www.codeweavers.com