Comfy Cats Effect room. Ask questions. Rant about config file formats. Be nice!
This is a common theme in a lot of features of effect types, btw. ;-) Many features sound amazing on paper but end up having little or no benefit in practical applications. That doesn't mean they're bad features, per se, but they may not be as compelling as they seem at first glance. Effect types are hard to reason about.
If I use Async.async() inside of Resource.use(), I need to ensure myself that somehow the async operation is completed prior to the resource's release method is called
The use method will not be called until (at least!) the callback inside of async is run. Which is to say, you have control over it. Remember that async doesn't mean "parallel", it just means non-blocking.
Sorry, I meant something different: during resource construction, I acquire a Resource
R. Within the use method I use Async.async() on R (so the callback necessarily has to be called after the use method). Assuming I am not altering ExecutionContexts or ContextShifts, is it possible for the release method to be called prior to the callback finishing if I do not explicitly synchronize this?
it's called within
use, not after
if you use
start, then you have a problem
because you escape the resource scope
(This code is bridging CompletableFuture, which is why I'm asking)
if you use
async, you will be safe
also, monix-catnap gives you the machinery to lift CompletableFuture so you don't have to worry about it
so, CPS basically
but I explain better in the talk
generally, "the IO completes" means "a callback was called"
you just don't see it most of the time
with
async you see it
and that's CPS again
a synchronous return is a built-in callback basically
I really need to get my coworkers on-board with this so I can do this at my day job and really dig into it
and it actually helps to think about how normal function calls in side-effecting code work
that return address is invisible to you as a programmer
CPS makes it visible, and it's represented as
A => Unit
i.e what to call to "return"
so
foo = bar(a) becomes bar(a, foo => everythingElse)
and
bar(a: A, logicalReturn: A => Unit) = ...., logicalReturn(result)
well, not necessarily literally