HORIZON HASKELLDocslts/ghc-9.10.x248f8f02026-10-05Search names, modules, packages, or :: a typeCtrl K

GHC 9.10.3 · lts/ghc-9.10.x · 248f8f0 · 2026-10-05

Moduleconduit-extra-1.3.8Haskell2010

Data.Conduit.ByteString.Builder

Convert a stream of blaze-builder Builders into a stream of ByteStrings.

Works with both blaze-builder < 0.4's Builders and Builder.

Adapted from blaze-builder-enumerator, written by myself and Simon Meier.

Note that the functions here can work in any monad built on top of IO or ST.

Since 1.1.7.0

  • 1 type
  • 7 values

Conduits from builders to bytestrings

3 declarations

Incrementally execute builders on the given buffer and pass on the filled chunks as bytestrings. Note that, if the given buffer is too small for the execution of a build step, a larger one will be allocated.

WARNING: This conduit yields bytestrings that are NOT referentially transparent. Their content will be overwritten as soon as control is returned from the inner sink!

Flush

Buffer allocation strategies

3 declarations
typetype BufferAllocStrategy = (IO Buffer, Int -> Buffer -> IO (IO Buffer))
#

A buffer allocation strategy (buf0, nextBuf) specifies the initial buffer to use and how to compute a new buffer nextBuf minSize buf with at least size minSize from a filled buffer buf. The double nesting of the IO monad helps to ensure that the reference to the filled buffer buf is lost as soon as possible, but the new buffer doesn't have to be allocated too early.

The simplest buffer allocation strategy: whenever a buffer is requested, allocate a new one that is big enough for the next build step to execute.

NOTE that this allocation strategy may spill quite some memory upon direct insertion of a bytestring by the builder. Thats no problem for garbage collection, but it may lead to unreasonably high memory consumption in special circumstances.

An unsafe, but possibly more efficient buffer allocation strategy: reuse the buffer, if it is big enough for the next build step to execute.