On Thu, Jul 23, 2009 at 1:50 PM, Juan Lang<juan.l...@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.