<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - every fd is forced to blocking on win32"
href="https://bugs.freedesktop.org/show_bug.cgi?id=69526#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - every fd is forced to blocking on win32"
href="https://bugs.freedesktop.org/show_bug.cgi?id=69526">bug 69526</a>
from <span class="vcard"><a class="email" href="mailto:pierre-bugzilla@ossman.eu" title="Pierre Ossman <pierre-bugzilla@ossman.eu>"> <span class="fn">Pierre Ossman</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=69526#c4">comment #4</a>)
<span class="quote">> 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.</span >
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]
<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms741576%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/ms741576%28v=vs.85%29.aspx</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>