Packages

package io

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. All

Type Members

  1. abstract class AbstractByteWriter extends ByteWriter

    An abstract implementation that implements the floating point methods in terms of integer methods.

  2. abstract class Buf extends AnyRef

    Buf represents a fixed, immutable byte buffer with efficient positional access.

    Buf represents a fixed, immutable byte buffer with efficient positional access. Buffers may be sliced and concatenated, and thus be used to implement bytestreams.

    See also

    com.twitter.io.Buf.ByteArray for an Array[Byte] backed implementation.

    com.twitter.io.Buf.ByteBuffer for an nio.ByteBuffer backed implementation.

    com.twitter.io.Buf.apply for creating a Buf from other Bufs

    com.twitter.io.Buf.Empty for an empty Buf.

  3. trait BufByteWriter extends ByteWriter

    A ByteWriter that results in an owned Buf

  4. class BufInputStream extends InputStream
  5. final class Bufs extends AnyRef

    A Java adaptation of the com.twitter.io.Buf companion object.

  6. trait ByteReader extends AutoCloseable

    A ByteReader provides a stateful API to extract bytes from an underlying buffer, which in most cases is a Buf.

    A ByteReader provides a stateful API to extract bytes from an underlying buffer, which in most cases is a Buf. This conveniently allows codec implementations to decode frames, specifically when they need to decode and interpret the bytes as a numeric value.

    Note

    Unless otherwise stated, ByteReader implementations are not thread safe.

  7. trait ByteWriter extends AnyRef

    ByteWriters allow efficient encoding to a buffer.

    ByteWriters allow efficient encoding to a buffer. Concatenating Bufs together is a common pattern for codecs (especially on the encode path), but using the concat method on Buf results in a suboptimal representation. In many cases, a ByteWriter not only allows for a more optimal representation (i.e., sequential accessible out regions), but also allows for writes to avoid allocations. What this means in practice is that builders are stateful. Assume that the builder implementations are ""not"" threadsafe unless otherwise noted.

  8. class InputStreamReader extends Reader[Buf] with Closable with CloseAwaitably

    Provides the Reader API for an InputStream.

    Provides the Reader API for an InputStream.

    The given InputStream will be closed when Reader.read reaches the EOF or a call to discard() or close().

  9. final class Pipe[A <: Buf] extends Reader[A] with Writer[A]

    A synchronous in-memory pipe that connects Reader and Writer in the sense that a reader's input is the output of a writer.

    A synchronous in-memory pipe that connects Reader and Writer in the sense that a reader's input is the output of a writer.

    A pipe is structured as a smash of both interfaces, a Reader and a Writer such that can be passed directly to a consumer or a producer.

    def consumer(r: Reader[Buf]): Future[Unit] = ???
    def producer(w: Writer[Buf]): Future[Unit] = ???
    
    val p = new Pipe[Buf]
    
    consumer(p)
    producer(p)

    Reads and writes on the pipe are matched one to one and only one outstanding read or write is permitted in the current implementation (multiple pending writes or reads resolve into IllegalStateException while leaving the pipe healthy). That is, the write (its returned Future) is resolved when the read consumes the written data.

    Here is, for example, a very typical write-loop that writes into a pipe-backed Writer:

    def writeLoop(w: Writer[Buf], data: List[Buf]): Future[Unit] = data match {
      case h :: t => p.write(h).before(writeLoop(w, t))
      case Nil => w.close()
    }

    Reading from a pipe-backed Reader is no different from working with any other reader:

    def readLoop(r: Reader[Buf], process: Buf => Future[Unit]): Future[Unit] = r.read().flatMap {
      case Some(chunk) => process(chunk).before(readLoop(r, process))
      case None => Future.Done
    }

    Thread Safety

    It is safe to call read, write, fail, discard, and close concurrently. The individual calls are synchronized on the given Pipe.

    Closing or Failing Pipes

    Besides expecting a write or a read, a pipe can be closed or failed. A writer can do both close and fail the pipe, while reader can only fail the pipe via discard.

    The following behavior is expected with regards to reading from or writing into a closed or a failed pipe:

    • Writing into a closed pipe yields IllegalStateException
    • Reading from a closed pipe yields EOF (Future.None)
    • Reading from or writing into a failed pipe yields a failure it was failed with

    It's also worth discussing how pipes are being closed. As closure is always initiated by a producer (writer), there is a machinery allowing it to be notified when said closure is observed by a consumer (reader).

    The following rules should help reasoning about closure signals in pipes:

    - Closing a pipe with a pending read resolves said read into EOF and returns a Future.Unit - Closing a pipe with a pending write fails said write with IllegalStateException and returns a future that will be satisfied when a consumer observes the closure (EOF) via read - Closing an idle pipe returns a future that will be satisfied when a consumer observes the closure (EOF) via read

  10. trait Reader[+A] extends AnyRef

    A Reader represents a stream of As.

    A Reader represents a stream of As.

    Readers permit at most one outstanding read.

    A

    the type of objects produced by this reader

  11. final class Readers extends AnyRef

    Java APIs for Reader.

    Java APIs for Reader.

    See also

    com.twitter.io.Reader

  12. trait Writer[-A] extends Closable

    A Writer represents a sink for a stream of As, providing a convenient interface for the producer of such streams.

  13. final class Writers extends AnyRef

    Java APIs for Writer.

    Java APIs for Writer.

    See also

    com.twitter.io.Writer

Value Members

  1. object Buf

    Buf wrapper-types (like Buf.ByteArray and Buf.ByteBuffer) provide Shared and Owned APIs, each of which with construction & extraction utilities.

    Buf wrapper-types (like Buf.ByteArray and Buf.ByteBuffer) provide Shared and Owned APIs, each of which with construction & extraction utilities.

    The Owned APIs may provide direct access to a Buf's underlying implementation; and so mutating the data structure invalidates a Buf's immutability constraint. Users must take care to handle this data immutably.

    The Shared variants, on the other hand, ensure that the Buf shares no state with the caller (at the cost of additional allocation).

    Note: There are Java-friendly APIs for this object at com.twitter.io.Bufs.

  2. object BufByteWriter
  3. object BufReader
  4. object ByteReader
  5. object ByteWriter
  6. object Charsets

    A set of java.nio.charset.Charset utilities.

  7. object Files

    Utilities for working with java.io.Files

  8. object InputStreamReader
  9. object Pipe
  10. object Reader
  11. object StreamIO
  12. object TempDirectory
  13. object TempFile
  14. object Writer

    See also

    Writers for Java friendly APIs.

Ungrouped