Timed

trait Timed[F[_], O]

An abstraction for writing Pull computations that can timeout while reading from a Stream.

A Pull.Timed is not created or intepreted directly, but by calling Stream.ToPull.timed.

yourStream.pull.timed(tp => ...).stream

The argument to timed is a Pull.Timed[F, O] => Pull[F, O2, R] function, which describes the pulling logic and is often recursive, with shape:

def go(timedPull: Pull.Timed[F, A]): Pull[F, B, Unit] =
 timedPull.uncons.flatMap {
   case Some((Right(chunk), next)) => doSomething >> go(next)
   case Some((Left(_), next)) => doSomethingElse >> go(next)
   case None => Pull.done
 }

Where doSomething and doSomethingElse are Pull computations such as Pull.output, in addition to Pull.Timed.timeout.

See below for detailed descriptions of timeout and uncons, and look at the Stream.ToPull.timed scaladoc for an example of usage.

class Object
trait Matchable
class Any

Type members

Types

type Timeout

Value members

Abstract methods

Asynchronously starts a timeout that will be received by uncons after t, and immediately returns.

Asynchronously starts a timeout that will be received by uncons after t, and immediately returns.

Timeouts are resettable: if timeout executes whilst a previous timeout is pending, it will cancel it before starting the new one, so that there is at most one timeout in flight at any given time. The implementation guards against stale timeouts: after resetting a timeout, a subsequent uncons is guaranteed to never receive an old one.

Timeouts can be reset to any t, longer or shorter than the previous timeout, but a duration of 0 is treated specially, in that it will cancel a pending timeout but not start a new one.

Note: If for some reason you insert a pause in between uncons and timeout, such as:

timedPull.timeout(n.millis) >>
 Pull.eval(IO.sleep(m.millis)) >>
 timedPull.uncons.flatMap { ...

you should be aware that an invocation of timeout that happens before the very first uncons will start the timeout simultaneously with the very first uncons. Subsequent invocations of timeout start the timeout immediately instead.

This is an implementation detail which should not affect most cases, given that usually there is no need to sleep in between timeout and the very first call to uncons.

def uncons: Pull[F, INothing, Option[(Either[Timeout, Chunk[O]], Timed[F, O])]]

Waits for either a chunk of elements to be available in the source stream, or a timeout to trigger. Whichever happens first is provided as the resource of the returned pull, alongside a new timed pull that can be used for awaiting again. A None is returned as the resource of the pull upon reaching the end of the stream.

Waits for either a chunk of elements to be available in the source stream, or a timeout to trigger. Whichever happens first is provided as the resource of the returned pull, alongside a new timed pull that can be used for awaiting again. A None is returned as the resource of the pull upon reaching the end of the stream.

Receiving a timeout is not a fatal event: the evaluation of the current chunk is not interrupted, and the next timed pull is still returned for further iteration. The lifetime of timeouts is handled by explicit calls to the timeout method: uncons does not start, restart or cancel any timeouts.

Note that the type of timeouts is existential in Pull.Timed (hidden, basically) so you cannot do anything on it except for pattern matching, which is best done as a Left(_) case.