Why does the haskell network library use non-blocking sockets?

Question

I am trying to better understand the design decision made in the network library. Reputation sources mention in the github question and the mailing list answer that network uses non-blocking sockets. Instead of using the default locking behavior, they use select to lock until the socket is ready to read. Why is it better? In any case, it ends with a lock, and network provides only a blocking API for end users. I assume this is bad for calling FFI to lock and that there is some kind of GHC magic around select , but I couldn’t confirm this.

As a secondary, I cannot find where select in the network call. Code base grabbing failed. I just discovered GHC.Event , which seems to provide functions that will be used instead of directly calling select , but grepping shows network does not use this.

Answer 1

The non-blocking I / O event loop is part of the GHC Runtime System (RTS). This works very well with the GHC green threading system: instead of writing asynchronous code, you can just use lightweight threads, and the runtime will take care to wake up the correct one.

All IOs in Haskell are not blocked by default, so if you have two threads, each of which is blocked on a different socket, then the runtime system will execute select internally (or some other way for the platform to wait for several file descriptors, such as epoll or kqueue ) to only wake the stream when the file descriptor is ready. See https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/IOManager for details.