<div class="gmail_quote">Hi Thu,<br><br>On Thu, Aug 26, 2010 at 11:13 AM, Vo Minh Thu <span dir="ltr"><<a href="mailto:noteed@gmail.com">noteed@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Is is possible to get Network.Socket.ByteString.recv to be<br>
non-blocking (i.e. return directly even if no data is available) ?<br></blockquote><div><br>Unfortunately not.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I have tried ti use<br>
<br>
setSocketOption sock NoDelay 1<br>
<br>
but then I get the following error:<br>
<br>
setSocketOption: unsupported operation (Protocol not available)<br></blockquote><div><br>Sockets are already set to be non-blocking and the blocking semantics are implemented on top of non-blocking sockets using e.g. the select system call. It's not the recv syscall that blocks but the I/O manager who blocks you're thread because recv returned WOULD_BLOCK. The I/O manager calls threadWaitRead upon receiving this error. threadWaitRead puts the thread to sleep until the socket is readable (as indicated by select).<br>
<br>We could perhaps implement a truly non-blocking API.<br><br>Cheers,<br>Johan<br><br></div></div>