@hackage sockets0.5.0.0

High-level network sockets

  • Installation

  • Dependencies (70)

  • Dependents (0)

    • Package Flags

      mmsg
       (off by default)

      Use sendmmsg and recvmmsg

      verbose-errors
       (off by default)

      More informative messages from internal errors

      debug
       (off by default)

      Print debug output

      checked
       (off by default)

      Add bounds-checking to primitive array operations

      example
       (off by default)

      Build example executables

This library provides a high-level abstraction for network sockets. It uses Haskell2010 (along with GADTs) without typeclasses to ensure that consumers of the API can only call appropriate functions on a socket.

Exceptions are tracked in the types of functions and returned to the caller with Either. The caller is free to handle these gracefully or to throw them. This library has another class of exceptions described as _unrecoverable_. This library only throws exceptions in three situations:

  • The library detects that it has misused the operating system's sockets API. This includes getting a sockaddr with an unexpected socket family. It also includes getting an error code that should not be possible. For example, the abstractions provided for both datagram sockets and stream sockets mean that send system calls in either context should never return the error code ENOTCONN. Consequently, this error is treated as unrecoverable.

  • The caller asks for a negatively-sized slice of a buffer (such exceptions indicate a mistake in the code consuming this API).

  • A system call fails with ENOBUFS or ENOMEM. These indicate that the operating system is out of memory. If this happens, the Out Of Memory (OOM) manager is likely killing processes to reclaim memory, so the process that received this message may be killed soon. Making things even worse is that the GHC runtime requests pages of memory from the operating system at times that are effectively unpredictable to Haskell developers. (Most memory-managed languages have this behavior). Any attempt to recover from ENOBUFS or ENOMEM might cause the runtime to allocate memory from the operating system. According to the documentation for the HeapOverflow exception, an allocation failure at this point in time (likely given the recent ENOBUFS/ENOMEM) would result in immidiate termination of the program. So, although it is technically possible to recover from ENOBUFS/ENOMEM, the OOM killer and the GHC runtime make it impossible to do so reliably. Consequently, these error codes are treated as fatal.