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
13h3r2
@13h3r2
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
that makes sense
Oleg Pyzhcov
@oleg-py
which is a fairly large number, but it can be customized
13h3r2
@13h3r2
Thanks. I will try to lower the limit it drop you guys a line
λoλcat
@catostrophe

Hi.
Is this behavior of bracket correct?

import cats.data.{Chain, WriterT}
import cats.effect.{ExitCode, IO, IOApp, Sync}
import cats.effect.implicits._
import cats.implicits._
import cats.mtl.FunctorTell
import cats.mtl.implicits._

object Test extends IOApp {

  def bracketWithTell[F[_], A](a: A)(implicit F: Sync[F], W: FunctorTell[F, Chain[String]]): F[ExitCode] =
    a.pure[F].bracket { x =>
      F.delay(println(s"used $x")) *> W.tell(Chain.one(s"used $x")) as ExitCode.Success
    } { x =>
      F.delay(println(s"released $x")) *> W.tell(Chain.one(s"released $x"))
    }

  override def run(args: List[String]): IO[ExitCode] =
    bracketWithTell[WriterT[IO, Chain[String], ?], Int](1).run.flatMap {
      case (log, code) => IO(println(s"writer log: $log")) as code
    }
}

Output:

used 1
released 1
writer log: Chain(used 1)

We lose the writer effect in the release part. The same holds for all transformers.

If it's correct, doesn't it need clarification in docs?

λoλcat
@catostrophe
bracket implementations for all transformers just ignore additional effects