2010/8/26 Johan Tibell <[email protected]>:
> Hi Thu,
>
> On Thu, Aug 26, 2010 at 11:13 AM, Vo Minh Thu <[email protected]> wrote:
>>
>> Is is possible to get Network.Socket.ByteString.recv to be
>> non-blocking (i.e. return directly even if no data is available) ?
>
> Unfortunately not.
>
>>
>> I have tried ti use
>>
>>  setSocketOption sock NoDelay 1
>>
>> but then I get the following error:
>>
>>  setSocketOption: unsupported operation (Protocol not available)
>
> 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).

Ok, that explains also why using fcntl directly on the fd didn't work
either. So, I think I will go the FFI road and create my socket the
way I want. Do you see another way?

> We could perhaps implement a truly non-blocking API.

If it is widely useful, I guess it would be great. I don't mind
writing some C and using the FFI though.

Thanks for your answer,
Thu
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to