Commit c327850d9e4479a0572b7baaf8dafd737586e5a1 looks highly suspicious to me. Why should read/write be blocking on Windows but not on other platforms? This commit will cause issues with responsiveness on Windows, so it needs to be reverted. Whatever other bug this commit was supposed to work around should be tracked down and fixed properly instead.
Created attachment 86362 [details] [review] 0003-core-make-sure-win32-sockets-remain-blocking.patch
Created attachment 86363 [details] [review] 0004-Revert-core-Transparently-handle-non-blocking-socket.patch
Found and fixed the original bug. Please apply.
c327850d9e4479a0572b7baaf8dafd737586e5a1 was indeed a work-around for pa_read() returning an error (EWOULDBLOCK) for sockets that should normally block. What "documented side effect" are you talking about specifically? The WSAEventSelect docs are long and confusing.
Thanks for the patches, I applied them now.
(In reply to comment #4) > c327850d9e4479a0572b7baaf8dafd737586e5a1 was indeed a work-around for > pa_read() returning an error (EWOULDBLOCK) for sockets that should normally > block. > > What "documented side effect" are you talking about specifically? The > WSAEventSelect docs are long and confusing. Yeah, Microsoft's socket API is not their finest work. :) On the MSDN Library page for WSAEventSelect()[1] we can read: "The WSAEventSelect function automatically sets socket s to nonblocking mode, regardless of the value of lNetworkEvents. To set socket s back to blocking mode, it is first necessary to clear the event record associated with socket s via a call to WSAEventSelect with lNetworkEvents set to zero and the hEventObject parameter set to NULL. You can then call ioctlsocket or WSAIoctl to set the socket back to blocking mode." [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms741576%28v=vs.85%29.aspx
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.