HORIZON HASKELLDocslts/ghc-9.14.xd82dee82026-10-12Search names, modules, packages, or :: a typeCtrl K

GHC 9.14.1 · lts/ghc-9.14.x · d82dee8 · 2026-10-12

Modulenetwork-mux-0.11.0.0Haskell2010

Network.Mux.Channel

An extension of Channel, with additional Channel implementations.

  • 2 types
  • 13 values

Channel

1 declaration
datadata Channel (m :: Type -> Type) a
#

A channel which can send and receive values.

It is more general than what `network-mux` requires, see ByteChannel instead. However this is useful for testing purposes when one is either using mux or connecting two ends directly.

Constructors

  • Channel
    • send :: a -> m ()

      Write bytes to the channel.

      It maybe raise exceptions.

    • recv :: m (Maybe a)

      Read some input from the channel, or Nothing to indicate EOF.

      Note that having received EOF it is still possible to send. The EOF condition is however monotonic.

      It may raise exceptions (as appropriate for the monad and kind of channel).

Channel API

valuedelayChannel :: MonadDelay m => DiffTime -> Channel m a -> Channel m a
#

Delay a channel on the receiver end.

This is intended for testing, as a crude approximation of network delays. More accurate models along these lines are of course possible.

create a Channel

connected Channels

ByteChannel

1 declaration

create a ByteChannel

valuehandlesAsChannel
  1. :: Handle

    Read handle

  2. -> Handle

    Write handle

  3. -> Channel IO ByteString
#

Make a Channel from a pair of IO Handles, one for reading and one for writing.

The Handles should be open in the appropriate read or write mode, and in binary mode. Writes are flushed after each write, so it is safe to use a buffering mode.

For bidirectional handles it is safe to pass the same handle for both.

valuewithFifosAsChannel
  1. :: FilePath

    FIFO for reading

  2. -> FilePath

    FIFO for writing

  3. -> (ByteChannel IO -> IO a)
  4. -> IO a
#

Open a pair of Unix FIFOs, and expose that as a Channel.

The peer process needs to open the same files but the other way around, for writing and reading.

This is primarily for the purpose of demonstrations that use communication between multiple local processes. It is Unix specific.

connected ByteChannels

Create a pair of Channels that are connected internally.

This is intended for inter-thread communication, such as between a multiplexing thread and a thread running a peer.

It uses lazy ByteStrings but it ensures that data written to the channel is fully evaluated first. This ensures that any work to serialise the data takes place on the writer side and not the reader side.