sockets
High-level network sockets
https://github.com/andrewthad/sockets
Latest on Hackage: | 0.7.0.0 |
This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow stackage.org to host generated Haddocks.
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.