Timed
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.
- Source:
- Pull.scala
Type members
Types
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
.
- Source:
- Pull.scala
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.
- Source:
- Pull.scala