|
Blaze.ByteString.Builder.Internal.Buffer | Portability | tested on GHC only | Stability | experimental | Maintainer | Simon Meier <iridcode@gmail.com> |
|
|
|
|
|
Description |
Execution of the Put monad and hence also Builders with respect to
buffers.
|
|
Synopsis |
|
|
|
|
Buffers
|
|
|
A buffer Buffer fpbuf p0 op ope describes a buffer with the underlying
byte array fpbuf..ope, the currently written slice p0..op and the free
space op..ope.
|
|
|
Status information
|
|
|
The size of the free space of the buffer.
|
|
|
The size of the written slice in the buffer.
|
|
|
The size of the whole byte array underlying the buffer.
|
|
Creation and modification
|
|
|
allocBuffer size allocates a new buffer of size size.
|
|
|
Resets the beginning of the next slice and the next free byte such that
the whole buffer can be filled again.
|
|
|
Move the beginning of the slice to the next free byte such that the
remaining free space of the buffer can be filled further. This operation
is safe and can be used to fill the remaining part of the buffer after a
direct insertion of a bytestring or a flush.
|
|
|
Update the end of slice pointer.
|
|
|
Execute a build step on the given buffer.
|
|
Conversion to bytestings
|
|
|
Convert the buffer to a bytestring. This operation is unsafe in the sense
that created bytestring shares the underlying byte array with the buffer.
Hence, depending on the later use of this buffer (e.g., if it gets reset and
filled again) referential transparency may be lost.
|
|
|
Convert a buffer to a non-empty bytestring. See unsafeFreezeBuffer for
the explanation of why this operation may be unsafe.
|
|
Buffer allocation strategies
|
|
|
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.
|
|
Executing puts respect to some monad
|
|
|
Execute a put on a buffer.
TODO: Generalize over buffer allocation strategy.
|
|
Produced by Haddock version 2.6.1 |