Output Streams
==============

'lib/ostream.h' describes Dovecot's output streams. Output streams can be
stacked on top of each others as many times as wanted.

Output streams actually writing data:

 * file: Write to given fd using 'pwrite()' for files and 'write()' for
   non-files.
 * unix: Write to given UNIX socket. Similar to file, but supports sending file
   descriptors.
 * buffer: Write to <buffer> [Design.Buffers.txt].

Output stream filters:

 * hash: Calculate hash of the ostream while it's being written.
 * escaped: Write output escaped via callback. Built-in support for HEX and
   JSON escaping.
 * multiplex: Multiplex-iostreams support multiple iostream channels inside a
   single parent istream.
 * null: All the output is discarded.
 * failure-at: Insert a failure at the specified offset. This can be useful for
   testing.
 * lib-mail/ostream-dot: Write SMTP-style DATA input where the output ends with
   an empty "." line.
 * lib-dcrypt/encrypt: Write encrypted data.
 * lib-compression/*: Write zlib/bzlib/lz4/lzma compressed data.

A typical life cycle for an ostream can look like:

 * create
 * 'o_stream_cork()'
 * 'o_stream_nsend*()' one or more times
 * 'o_stream_uncork()'
 * If necessary, check errors with 'o_stream_flush()'
 * 'o_stream_cork()'
 * 'o_stream_nsend*()' one or more times
 * 'o_stream_uncork()'
 * finalize the ostream with 'o_stream_finish()'
 * optionally close the ostream with 'o_stream_close()'
 * unref or destroy

Once the ostream is finished, it can't be written to anymore. The
'o_stream_finish()' call writes any potential trailer that the ostream may have
(e.g. ostream-gz, ostream-encrypt, ostream-dot) while still allowing the caller
to check if the trailer write failed. After 'o_stream_finish()' is called, any
further write will panic. The ostreams that require a trailer will panic if
'o_stream_finish()' hasn't been called before the stream is destroyed, but
other ostreams don't currently require this. Still, it's not always easy to
know whether there might be ostreams that require the trailer, so if there's
any doubt, it's preferred to call 'o_stream_finish()' just before destroying
the ostream.

Usually calling 'o_stream_finish()' will also finish its parent ostream. This
may or may not be wanted depending on the situation. For example ostream-dot
must be finished to write the last "." line, but ostream-dot is always a
sub-stream of something else that must not be finished yet. This is why
ostream-dot by default has called 'o_stream_set_finish_also_parent(FALSE)', so
finishing the ostream-dot won't finish the parent stream. Similarly
'connection.c' API sets 'o_stream_set_finish_via_child(FALSE)' so none of the
socket connections created via it will be finished even though one of their
sub-streams is finished. These functions may need to be called explicitly in
other situations.

When doing a lot of writes, you can simplify the error handling by delaying the
error checking. Use the 'o_stream_nsend*()' functions and afterwards check the
error with 'o_stream_flush()' or 'o_stream_finish()'. If you forgot to do this
check before the ostream is destroyed, it will panic with:'output stream %s is
missing error handling' regardless of whether there is an error or not. If you
don't care about errors for the ostream (e.g. because it's a client socket and
there's nothing you can do about the write errors), you can use
'o_stream_set_no_error_handling()' to fully disable error checks. You can also
use 'o_stream_ignore_last_errors()' to ignore the errors so far, but not for
future writes.

Writes are non-buffered by default. To add buffering, use 'o_stream_cork()' to
start buffering and 'o_stream_uncork()' to stop/flush. When output buffer gets
full, it's automatically flushed even while the stream is corked. The term
"cork" is used because with TCP connections the call actually sets/removes TCP
cork option. It's quite easy to forget to enable the corking with files, making
the performance worse. The corking/uncorking is done automatically when flush
callbacks are called. Using 'o_stream_uncork()' will trigger an automatic
'o_stream_flush()' but the error is ignored. This is why it acts similarly to
'o_stream_nsend*()', i.e. it requires another explicit 'o_stream_flush()',
'o_stream_finish()' or error ignoring before the ostream is destroyed.

If output buffer's size isn't unlimited, the writes can also fail or be partial
because there's no more space in the buffer and 'write()' syscall is returning
'EAGAIN'. This of course doesn't happen with blocking fds (e.g. files), but you
need to handle this in some way with non-blocking network sockets. A common way
in Dovecot to handle this is to just use unlimited buffer sizes and after each
write check if the buffer size becomes too large, and when it does it stops
writing until more space is available.

(This file was created from the wiki on 2019-03-05 04:42)