Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 05 2019 14:43
    @typelevel-bot banned @jdegoes
  • Jan 31 2019 21:17
    codecov-io commented #484
  • Jan 31 2019 21:08
    scala-steward opened #484
  • Jan 31 2019 18:19
    andywhite37 commented #189
  • Jan 31 2019 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 2019 00:01
    codecov-io commented #483
  • Jan 29 2019 23:51
    deniszjukow opened #483
  • Jan 29 2019 23:37
  • Jan 29 2019 23:22
  • Jan 29 2019 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 2019 18:01
    jdegoes commented #480
  • Jan 29 2019 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 2019 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 2019 07:12
    alexandru commented #480
  • Jan 28 2019 05:45
    codecov-io commented #482
  • Jan 28 2019 05:35
    daron666 opened #482
  • Jan 27 2019 13:56
    codecov-io commented #481
  • Jan 27 2019 13:46
    lrodero opened #481
  • Jan 27 2019 05:47
    codecov-io commented #460
  • Jan 27 2019 05:37
    codecov-io commented #460
Daniel Spiewak
@djspiewak
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.
Bob Glamm
@glammr1
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 (assuming that release destroys a critical resource that the async operation depends on), right?
Daniel Spiewak
@djspiewak

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.

Bob Glamm
@glammr1
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?
Fabio Labella
@SystemFw

so the callback necessarily has to be called after the use method)

that's not the case if I understand correctly

it's called within use, not after
Bob Glamm
@glammr1
Yes, sorry, I was envisioning order of execution in my head so I used the word after
Fabio Labella
@SystemFw
and async returns only when the callback is called (it's not start, there is no logical forking)
Bob Glamm
@glammr1
Ok, so if I understand that correctly async must complete before use can complete, which means that invoking async within use should be safe
Fabio Labella
@SystemFw
yes
if you use start, then you have a problem
because you escape the resource scope
Bob Glamm
@glammr1
That's some magic library code if voluntary yielding is in place for async?
(This code is bridging CompletableFuture, which is why I'm asking)
Fabio Labella
@SystemFw
not sure what you mean
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
Bob Glamm
@glammr1
I believe you, I am just trying to fill out my mental model of how async works :)
Fabio Labella
@SystemFw
my fiber talk goes into a lot of detail
Bob Glamm
@glammr1
I'll look at that talk again, I think I missed that detail on my first go-around. Thanks!
Fabio Labella
@SystemFw
the connection between returning and async is key
so, CPS basically
but I explain better in the talk
Bob Glamm
@glammr1
Nod. I just don't have a good model in my head for where all the continuations occur yet
Fabio Labella
@SystemFw
async exposes the bare structure
generally, "the IO completes" means "a callback was called"
you just don't see it most of the time
with async you see it
Bob Glamm
@glammr1
AHH. That comment actually helps quite a bit
Fabio Labella
@SystemFw
yeah
and that's CPS again
a synchronous return is a built-in callback basically
Bob Glamm
@glammr1
I at least remember that much from your description of the IO loop
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
Fabio Labella
@SystemFw
continuations really are very very fundamental once they click for you
and it actually helps to think about how normal function calls in side-effecting code work
Bob Glamm
@glammr1
Yeah, that's what Arrow's IO runloop is built on top of as well and I need to dig into that too. I expect the implementations are pretty similar, logically
Fabio Labella
@SystemFw
when you do foo = bar(a), something stores the address of where to go after bar is done, then runs bar (allocating stack space for its arguments and returned type). When bar calls return, control is transferred back to the previous stored place
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)
Bob Glamm
@glammr1
^^ The hard part for me is that I know exactly what that call frame looks like at an assembly level. Translating traditional call/ret stacks to continuations is less transparent to me
Fabio Labella
@SystemFw
do the final statements I have make any sense?
Bob Glamm
@glammr1
Yes, actually, that model makes quite a bit of sense
Fabio Labella
@SystemFw
that's the CPS transform
Bob Glamm
@glammr1
now I have it modeled in my head as more of a "hidden" parameter like this is on method calls
Fabio Labella
@SystemFw
yeah, that's what you normally have in most languages
well, not necessarily literally