Bug 69526

Summary:	every fd is forced to blocking on win32
Product:	PulseAudio	Reporter:	Pierre Ossman <pierre-bugzilla>
Component:	core	Assignee:	pulseaudio-bugs
Status:	RESOLVED FIXED	QA Contact:	pulseaudio-bugs
Severity:	normal
Priority:	medium	CC:	astrand, lennart
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	0003-core-make-sure-win32-sockets-remain-blocking.patch 0004-Revert-core-Transparently-handle-non-blocking-socket.patch

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.