Bug 69526 - every fd is forced to blocking on win32
Summary: every fd is forced to blocking on win32
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-18 12:44 UTC by Pierre Ossman
Modified: 2013-11-15 16:39 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0003-core-make-sure-win32-sockets-remain-blocking.patch (4.45 KB, patch)
2013-09-23 13:02 UTC, Pierre Ossman
Details | Splinter Review
0004-Revert-core-Transparently-handle-non-blocking-socket.patch (2.72 KB, patch)
2013-09-23 13:02 UTC, Pierre Ossman
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Ossman 2013-09-18 12:44:32 UTC
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.
Comment 1 Pierre Ossman 2013-09-23 13:02:42 UTC
Created attachment 86362 [details] [review]
0003-core-make-sure-win32-sockets-remain-blocking.patch
Comment 2 Pierre Ossman 2013-09-23 13:02:59 UTC
Created attachment 86363 [details] [review]
0004-Revert-core-Transparently-handle-non-blocking-socket.patch
Comment 3 Pierre Ossman 2013-09-23 13:03:26 UTC
Found and fixed the original bug. Please apply.
Comment 4 Thomas Martitz 2013-11-15 08:29:50 UTC
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.
Comment 5 Tanu Kaskinen 2013-11-15 09:05:57 UTC
Thanks for the patches, I applied them now.
Comment 6 Pierre Ossman 2013-11-15 16:39:12 UTC
(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.