IOinstead of a Future, then it's
ContextShift.evalOn(fa)is blocking as in : the calling thread is blocked until
fais finished evaluating. Whats the point of an API that evaluates a piece of code on another thread but blocks for it to finish as well ? Isn't the whole point of this to shift a (potentially blocking) piece of code to another thread so the current thread does not block and can continue ?
Syncyou can use the
ContextShiftto make that thread blocking execute on an EC you pick, usually one marked by
@ashkann As a pale (but more concise) shadow of Fabio's talk…
Threads are basically an implementation detail. They're an abstraction around CPUs. We tend to think of threads as strictly a mechanism for parallelism, but really they're a mechanism for evaluation just as the underlying processor is. Parallelism is when multiple sequences of computation are scheduled to run simultaneously or pseudo-simultaneously (by suspension and interleaving). We generally refer to those sequences as "fibers".
In Cats Effect, we talk a lot about spawning fibers (using
start) and getting their results (often using
join). Fibers can be scheduled to run in parallel with other fibers using threads as an implementation mechanism. The threads themselves though are not something we often consider (outside of making sure that our thread pools are correctly configured so the runtime behaves nicely) because they're really just an implementation detail of the runtime.
Fabio's talk is really good you should watch it :-)
fa, move it to another execution context, evaluate it and return back" while blocking the calling fiber (I understand the point is that the thread is not blocked, but fiber is blocked and it's ok to block a fiber). But can be achieved by that ? if we have to block then why take the trouble to evaluate it on a different
evalOn, at a fiber level nothing changes
evalOnwhen you're wrapping code which is actually thread blocking
evalOnis only there to help you deal with code which was not designed with the fiber model in mind
evalOndoesn't magically create asynchrony. It simply shifts the undesirable property of (true) blocking to an execution context that is designed for that kind of work. The logical flow of steps is still (semantically) blocked from a programmer's perspective because the calling fiber is blocked (not the underlying thread) and this is whole point.