blocking/non-blocking socket question.

[Mike Kaplinskiy]

On Thu, Jul 23, 2009 at 1:50 PM, Juan Lang<juan.lang at gmail.com> wrote:
>> It is calling recv() on a socket that was previously:
>> 1) set to blocking with a WS_ioctlsock() call with cmd WS_FIONBIO
>> 2) AsyncSelect()'ed that should make the socket non-blocking.
> (snip)
>> while the second does not touch the unix fd. This leaves the unix file
>> descriptor in the blocking state and the unix recvmsg() call will not
>> terminate.
>>
>> I thought the unix file descriptor should always by non-blocking, but it
>> is a while since I was looking at socket code.
>
> No, it's possible to make blocking socket calls in Windows too.  If
> you've left a socket in blocking mode, and call one of the blocking
> Winsock functions, like send() or recv(), Wine will call a Unix
> library function, like sendmsg() or recvmsg(), that will block too.
>
>> Is what I think correct, and should the fcntl()'s simply go. Or should
>> AsyncSelect() set the unix fd to non blocking instead?
>
> I guess you need tests to confirm that calling WSAAsyncSelect causes a
> socket to become nonblocking..
> --Juan
>
>
>

I think what Rein means is that the unix socket fd backing the windows
socket handle is always non-blocking - and if he is, he may be
correct:

http://source.winehq.org/source/server/sock.c#L578 &&
http://source.winehq.org/source/server/sock.c#L663

Any socket created by the wine server is automatically made
non-blocking. In order to block on windows sockets, we have a function
called do_block:
http://source.winehq.org/source/dlls/ws2_32/socket.c#L645 and
_is_blocking to do the actual blocking for us. An easy example of why
we do this is WS_accept. If we make the listening socket blocking, we
can "freeze" the wineserver.

I don't think we need to actually set the unix fd to non-blocking
during ioctlsocket, so just removing those fcntl's should work. Just
tested this and ws2_32&wininet tests still pass.

Should probably consult Alexandre though.

Mike.