RxnSignallingRef

Obtains a snapshot of the current value, and a setter for updating it.

The setter attempts to modify the contents from the snapshot to the new value (and return true). If it cannot do this (because the contents changed since taking the snapshot), the setter is a noop and returns false.

Satisfies: r.access.map(_._1) == r.get and r.access.flatMap { case (v, setter) => setter(f(v)) } == r.tryUpdate(f).map(_.isDefined).

Returns a stream of the current value and subsequent updates to this signal.

Even if you are pulling as fast as possible, updates that are very close together may result in only the last update appearing in the stream. In general, when you pull from this stream you may be notified of only the latest update since your last pull. If you want to be notified about every single update, use a Queue or Channel instead.

Like modify but schedules resulting effect right after modification.

Useful for implementing effectful transition of a state machine, in which an effect is performed based on current state and the state must be updated to reflect that this effect will be performed.

Both modification and finalizer are within a single uncancelable region, to prevent canceled finalizers from leaving the Ref's value permanently out of sync with effects actually performed. if you need cancellation mechanic in finalizer please see flatModifyFull.

Like modify but schedules resulting effect right after modification.

Unlike flatModify finalizer cancellation could be unmasked via supplied Poll. Modification itself is still uncancelable.

When used as part of a state machine, cancelable regions should usually have an onCancel finalizer to update the state to reflect that the effect will not be performed.

Like modifyState but schedules resulting effect right after state computation & update.

Both modification and finalizer are uncancelable, if you need cancellation mechanic in finalizer please see flatModifyStateFull.

Like modifyState but schedules resulting effect right after modification.

Unlike flatModifyState finalizer cancellation could be masked via supplied Poll[F]. Modification itself is still uncancelable.

Updates the current value using f and returns the previous value.

In case of retries caused by concurrent modifications, the returned value will be the last one before a successful update.

Sets the current value to a.

The returned action completes after the reference has been successfully set.

Update the value of this Ref with a state computation.

The current value of this Ref is used as the initial state and the computed output state is stored in this Ref after computation completes. If a concurrent modification occurs, None is returned.

Modifies the current value using the supplied update function. If another modification occurs between the time the current value is read and subsequently updated, the modification is retried using the new value. Hence, f may be invoked multiple times.

Satisfies: r.update(_ => a) == r.set(a)

Returns when the condition becomes true, semantically blocking in the meantime.

This method is particularly useful to transform naive, recursive polling algorithms on the content of a Signal/ SignallingRef into semantically blocking ones. For example, here's how to encode a very simple cache with expiry, pay attention to the definition of view:

trait Refresh[F[_], A] {
 def get: F[A]
}
object Refresh {
 def create[F[_]: Temporal, A](
   action: F[A],
   refreshAfter: A => FiniteDuration,
   defaultExpiry: FiniteDuration
 ): Resource[F, Refresh[F, A]] =
   Resource
     .eval(SignallingRef[F, Option[Either[Throwable, A]]](None))
     .flatMap { state =>
       def refresh: F[Unit] =
         state.set(None) >> action.attempt.flatMap { res =>
           val t = res.map(refreshAfter).getOrElse(defaultExpiry)
           state.set(res.some) >> Temporal[F].sleep(t) >> refresh
         }

       def view = new Refresh[F, A] {
         def get: F[A] = state.get.flatMap {
           case Some(res) => Temporal[F].fromEither(res)
           case None => state.waitUntil(_.isDefined) >> get
         }
       }

       refresh.background.as(view)
     }
}

Note that because Signal prioritizes the latest update when its state is updating very quickly, completion of the F[Unit] might not trigger if the condition becomes true and then false immediately after.

Therefore, natural use cases of waitUntil tend to fall into two categories: - Scenarios where conditions don't change instantly, such as periodic timed processes updating the Signal/SignallingRef. - Scenarios where conditions might change instantly, but the p predicate is monotonic, i.e. if it tests true for an event, it will test true for the following events as well. Examples include waiting for a unique ID stored in a Signal to change, or waiting for the value of the Signal of an ordered Stream[IO, Int] to be greater than a certain number.