Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not withhold emission in pauseWhen #2813

Merged
merged 2 commits into from
Feb 5, 2022

Conversation

SystemFw
Copy link
Collaborator

@SystemFw SystemFw commented Feb 5, 2022

pauseWhen should emit elements as soon as it wakes up, instead of checking for the need to pause again.

The difference in behaviour came up when I was implementing this (very complex) combinator for a user, which alternates between two streams upon a timeout.

def switchRepeat[A](
    every: FiniteDuration,
    to: Stream[IO, A]
): Pipe[IO, A, A] = { in =>
  Stream.eval(SignallingRef.of[IO, Boolean](true)).flatMap { paused =>
    val pause = Pull.eval(paused.set(true))
    val unpause = Pull.eval(paused.set(false))

    def go(p: Pull.Timed[IO, A]): Pull[IO, A, Unit] =
      p.timeout(every) >> p.uncons.flatMap {
        case Some((Right(elems), next)) =>
          pause >> Pull.output(elems) >> go(next)
        case Some((Left(_), next)) =>
          unpause >> go(next)
        case None =>
          Pull.done
      }

    val foreground = in.pull.timed(go).stream
    val background = to.through(pauseWhen(paused))

    foreground.mergeHaltL(background)
  }
}

Given how complex the example is, and how hard it is to engineer alternative code that would trigger a difference in behaviour between the new and old implementation of pauseWhen, I haven't added a test covering my change. Let me know if you want me to try harder finding a minimised test

@SystemFw SystemFw merged commit d8bac3a into typelevel:main Feb 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants