by

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
Fabio Labella
@SystemFw
so just having a chain of flatMaps doesn't mean you'll shift
IO leaves that to the user
13h3r2
@13h3r2
Sure, I can workaround this, but I am trying to figure out where to put shift in a future. And how expensive it is.
Fabio Labella
@SystemFw

in a future

do you mean "in the future" or "in a Future"

13h3r2
@13h3r2
Right now I am observing the behavior I do not understand. You pointed to huge chuck which is being called in the very first example. I split it, but behavior is the same and I can not explain it with small chunks.
In the future
Fabio Labella
@SystemFw
right
13h3r2
@13h3r2
I would expect that start of the fiber should auto shift and in the case of small chunks at least all .get ios will be executed first.
Fabio Labella
@SystemFw
the start of the fiber does auto-shift
then they all stop on get
then they all get awakened in order
then it depends: when you shift after get, each probably gets its own thread since you have 20
when you don't shift after get, you have this chain of flatMap (now)
and the behaviour is implementation specific: IO doesn't auto shift every n, so you need to do it manually if you want that
Monix should auto shift every n flatMap, if configured correctly (I think it does it by default)
13h3r2
@13h3r2
Did I get you right that in fact we are executing the code after .get sequentially on the thread where complete has been called?
Fabio Labella
@SystemFw
with Thread.sleep, I think so, yeah
13h3r2
@13h3r2
Should we shift every listener of deferred by default then. I am not expecting that the thread where I am calling complete will do any computation except for awakening other threads.
Fabio Labella
@SystemFw

Should we shift every listener of deferred by default then.

Define "we". Your code, or cats-effect?

13h3r2
@13h3r2
Cats effect
Fabio Labella
@SystemFw
I don't know
this is only a problem for blocking code
13h3r2
@13h3r2
As side effect we are also delaying the next execution after .complete
This is not only about blocking, this is also about cpu intensive operations.
Fabio Labella
@SystemFw
sure, but with cpu intensive operations I think it goes back to guarantees fo fairness
13h3r2
@13h3r2
So instead of notifying we are executing the whole other program which depends on this barrier
Fabio Labella
@SystemFw
shift on its own doesn't fix that. shift plus the fact that you happen to have lots of threads does
like, even if Deferred shifted, with 4 threads you'd still see lots of sequential behaviour
13h3r2
@13h3r2
Ah, I see it. You right.
Fabio Labella
@SystemFw
not saying that you don't have a problem ofc :)
13h3r2
@13h3r2
So shift + fairness can fix it
Fabio Labella
@SystemFw
just that your problem is more with fairness than with Deferred (or MVar, or Scala Promise)
well
with fairness guarantees you shouldn't need a manual shift
since fairness guarantees basically amount to shifting every now and then
if I were writing this code
since you know that that piece of code is very CPU-intensive
13h3r2
@13h3r2
Yes and no. The first iteration still will be sequential, right?
Fabio Labella
@SystemFw
sure
I don't think that's that big of a deal though, as long as control gets yielded back at some point
13h3r2
@13h3r2
Ok it make sense. Should we put the note about fairness and scheduling somewhere in the documentation?
Fabio Labella
@SystemFw
it's already there somewhere I think
in the differences between IO and Task
what's surprising here is the behaviour of Task
13h3r2
@13h3r2
For now (:)) it is clear for why it should not work with io. I will continue the investigation with task today.
Will start with the code from master
Thanks for your help!
Fabio Labella
@SystemFw
no worries
Oleg Pyzhcov
@oleg-py
The default for monix is to shift every 1024 binds IIRC
Fabio Labella
@SystemFw
ah, there it is