On Thu, Jul 23, 2009 at 1:50 PM, Juan Langjuan.lang@gmail.com wrote:
It is calling recv() on a socket that was previously:
- set to blocking with a WS_ioctlsock() call with cmd WS_FIONBIO
- 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.