the fact that you explicitly need a ContextShift will disappear in ce3 though (it's a bit of an implementation leak)
So the reason I don't need fibers in my implementation is because
background puts the entire implementation on another thread (is fiber a better word here?)? Also, Daniel inadvertently (I think) switched f and sleep so it's not quite the same? Just checking my understanding.
background is just a different combinator that uses Resource to manage start (i.e. a Fiber)
on the jvm this is also likely to mean a different thread, but this is a detail that you shouldn't need to know about
the latter usage is what
background abstracts for you
the first usage is not strictly needed because you
start and then immediately join
so basically all you are doing is introducing an async boundary, like you would with
IO.shift
but you don't need to do that as
sleep already does it under the hood
you also don't really need
handleErrorWith there
Also, Daniel inadvertently (I think) switched f and sleep so it's not quite the same? J
yeah I think so
@coltfred does that make sense or did I rush it?
they have very similar semantics, just managed by the kernel atop the processors
scala> (IO.raiseError(new Exception()) >> IO(println("foo"))).unsafeRunSync()
java.lang.Exception
... 11 elided
@SystemFw Ya, I think I've got it.
although in your specific case it's easier to do
f.attempt <* and no handleError at the end
since you essentially want to swallow your error
Fair enough.
background gives you an F[A] as the resource, which in the example is just thrown away. I was conducting a thought experiment where startUpdate would actually create the Ref and return it, but then I ended up with Resource[IO, IO[Ref[IO,A]]] so I need to flatMap on the value which I've gotten as the resource (which seems weird). Are there some examples where the value coming out of the IO that's being run by background is actually used?
//Update r every duration by running f.
def startUpdate[A](f: IO[A], duration: FiniteDuration): IO[Ref[IO, A]] = {
def loop(r: Ref[IO, A]): IO[Unit] = {
for {
_ <- IO.sleep(duration)
newValue <- f
_ <- r.set(newValue)
} yield ()
}.attempt >> loop(r)
for {
initial <- f
ref <- Ref.of[IO, A](initial)
_ <- loop(ref)
} yield ref
}
I guess in this case I've actually mixed things I want done once with things I want to background...
That's probably why it feels weird.
you are writing the equivalent of
fs2.hold basically
although
Stream.repeatEval(f).metered(duration).hold(initial).compile.resourceshould do the whole thing for you
it will be
Resource[F, Signal[F, A]] rather then Ref, but they both have .get: F[A]
Why does background give you F[A] for the value in the resource? I don't understand where or when that would be useful.
background basically means "spawns this fiber, but keep track of canceling if I get canceled for me"
the
F[A] that it returns you if the join on the fiber you have spawned
in this case you don't want that, since you are getting the results through the Ref instead (a pretty common pattern, which is why fs2 has
hold)
trait Fiber[F[_], A] {
def join: F[A] // wait for this fiber to complete, give me result
def cancel: F[Unit] // cancel and wait for the fiber to finalise
}
def start(fa: F[A]): F[Fiber[F, A]] // start a fiber with `fa`, and give a handle to wait for it or cancel it
as a refresher
whenever you use
start directly, you risk leaking a fiber (and the process you have spawned within it
since you can do
start >> doSomething or start.flatMap { doSomething with fiber
but if get canceled externally (e.g. by a call to
timeout), the fiber you have spawned would just keep going in the background