Basically, a “resource” is something that must be acquired (like a socket connection), used (effectfully), and released whether used successfully or unsuccessfully.
@bifunctor if you like this kind of thing, I made a vid about Resource (and Bracket, if you want to understand how Resource works with multiple effect types): https://www.youtube.com/watch?v=m9cu4xUvrUs
Hi
The docs of
The docs of
Blocker say that it shouldn't be passed implicitly (https://github.com/typelevel/cats-effect/blob/master/core/shared/src/main/scala/cats/effect/Blocker.scala#L31). What is the reason behind this recommendation? I used to pass it implicitly and haven't seen any obvious drawbacks so far.
@RafalSumislawski Just general best-practices with implicits. Basically,
implicit values should never hold state. The implications of this are pretty profound and far-reaching, and a lot of it comes from experience in violating this rule (and paying the price later). An analogous "best practice" is that you should never do something like implicit def strToInt(s: String): Int = .... You certainly can do this, and it'll work sometimes, but you would reject any PR that introduced something like that, wouldn't you? Same thing with implicit Blocker.
That was maybe too abstract. :-) It's hard to point to concrete examples of where
implicit Blocker will bite you. I guess the best thing to look at is the frustrations that people often have around implicit ExecutionContexts in the Future ecosystem.
Blocker is similar
@SystemFw I attended your talk at Scala World and you mentioned that the toy IO that you built there is not stack-safe. I have started playing around with the code from the slides and filled in the blanks ... and I'm having a hard time getting the stack to overflow. ^^
In what way isn't the IO from http://systemfw.org/Scala-World-2019/ stack-safe? Aren't
In what way isn't the IO from http://systemfw.org/Scala-World-2019/ stack-safe? Aren't
Pure/FlatMap + the run loop essentially a trampoline?
@djspiewak the most common issue I've seen with ExecutionContext is that a typical application needs more than one ec, this leaves a lot room for "accidentally passed the wrong one" errors. Typically an application needs just one Blocker wrapping an unlimited cachedThreadPool. A cached thread pool indeed has a state, but it's the kind of state that can't be observed. Compared to blocker, I see more risk in passing around implicit CountextShift, which typically boxes a limited thread pool, and through that limit the state (number of running tasks) of the thread pool can be observed (delayed execution) by a user of the context shift.
That is, as @djspiewak said, "Basically,
implicit values should never hold state."
@paul-snively-exa and what do you think about the inability to observe the state of a Blocker backed by a cachedThreadPool? I used to view it as a technical/JVM detail of execution, one that just like allocations, stack size limit etc, doesn't need special handling.
In this case, the reality is, you don’t have an unbounded number of cores.
At some point, when developing services at scale, I think you get radicalized about managing scarce resources explicitly.
That is, I'd add the warning to
ContextShift rather than removing it from Blocker.
But meh. I take your point, too, about expecting most of them to be blocked rather than actually consuming a core. That's not indefensible, any more than expecting not to OOM, acting as if memory were unbounded, is.
(re: implicit Blocker)
same that applies to stateful tagless algebras
basically the idea is that passing things implicitly does not really cause issues, it's implicit instances that can be troublesome (because you can pick up the wrong one by accident)
but if you pass something implicitly, but only make the correspondent instance implicit close to the call site, then it's ok
drawbacks:
- the language isn't great for this syntax wise, so you have some unwieldy bits, which are normally limited to
mainhowever - it's not a clear cut rule, so if your team disagrees, just passing things explicitly works better
@danielkarch hey,
Aren't Pure/FlatMap + the run loop essentially a trampoline?
well, you need to introduce an async boundary (or more), and then the execution context essentially acts as a trampoline (which is why Future is stack safe, it submits all the time). However having a fully async boundary (i.e. an ExecutionContext submission) is heavyweight, you can build a lighter weight one (this is trampolineEc in cats-effect).
The thing with stack-safety is that there are some corner cases (you will see comments in the cats-effect codebase like "we need to insert another async boundary here for stack-safety")
also, you will notice that in my code there is a comment saying "no double execution check" on
Async, so my async there is not idempotent (which it has to be)
all that being said, I'm planning to expand on that IO for blog post series and/or a playground for the new cancelation semantics (unfortunately the optimisations in cats-effect proper make the code quite convoluted and hard to experiment with, at least for me)
Hello guys!)
I’ve started exploring world of FP recently, and now I’m trying tu build my first http-service with http4s.
And I get these debug messages in my console (on every request that consul does):
Request headers: Headers(Host: docker.for.mac.localhost:7000, User-Agent: Consul Health Check, Accept: text/plain, text/*, */*, Accept-Encoding: gzip, Connection: close)
[21:31:24.850] [scala-execution-context-global-40 ] DEBUG - closeConnection()
[21:31:24.850] [scala-execution-context-global-40 ] DEBUG - Shutting down HttpPipeline
[21:31:24.850] [scala-execution-context-global-40 ] DEBUG - Canceled request
[21:31:24.850] [scala-execution-context-global-40 ] DEBUG - Shutting down.
[21:31:24.851] [scala-execution-context-global-40 ] DEBUG - Shutting down HttpPipeline
[21:31:24.851] [scala-execution-context-global-40 ] DEBUG - Canceled request
[21:31:24.851] [scala-execution-context-global-40 ] DEBUG - Shutting down.
[21:31:24.851] [scala-execution-context-global-40 ] DEBUG - Shutting down idle timeout stage
[21:31:24.851] [scala-execution-context-global-40 ] DEBUG - Shutting down.
[21:31:24.851] [scala-execution-context-global-40 ] DEBUG - Shutting down.
[21:31:24.851] [blaze-selector-7 ] DEBUG - Stage NIO1HeadStage sending inbound command: Disconnected
[21:31:24.851] [blaze-selector-7 ] DEBUG - Shutting down idle timeout stage
[21:31:24.851] [blaze-selector-7 ] DEBUG - Shutting down.
[21:31:24.851] [blaze-selector-7 ] DEBUG - Stage IdleTimeoutStage sending inbound command: Disconnected
[21:31:24.851] [blaze-selector-7 ] DEBUG - Shutting down HttpPipeline
[21:31:24.851] [blaze-selector-7 ] DEBUG - Canceled request
[21:31:24.851] [blaze-selector-7 ] DEBUG - Shutting down.My code looks like:
def apply[F[_]: Sync: Async](port: Int)(
implicit cs: ConcurrentEffect[F],
timer: Timer[F],
): F[Http4sPrometheusExporter] = {
for {
prometheusService <- Http4sPrometheusService.build[F]
httpApp = Router[F]("/" -> prometheusService.routes).orNotFound
server <- BlazeServerBuilder[F]
.bindHttp(port, "0.0.0.0")
.withHttpApp(httpApp)
.resource
.use(_ => Async[F].never[Unit])
.start
} yield new Http4sPrometheusExporter()
}Is it ok? Or I’m duing something wrong?
Appreciate any help :)
BTW api-endpoint seems to be working properly
for example the
Functor typeclass describes the behavior of map: F[A] => (A => B) => F[B] and laws like composition; fa.map(f).map(g) == fa.map(f andThen g)
