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
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
λoλcat
@catostrophe
There's no laws for release. Do we need some?
Fabio Labella
@SystemFw
@catostrophe I would open an issue with that snippet. Better to have everyone see it
λoλcat
@catostrophe
Ok. Will do
λoλcat
@catostrophe
Viktor Lövgren
@vlovgr
@catostrophe the same behaviour should happen when using asyncF, unless I'm mistaken. Have you tried it?
Luka Jacobowitz
@LukaJCB
@catostrophe I think it’s actually impossible to write a bracket implementation that does what you expect with its current signature
λoλcat
@catostrophe
@vlovgr you're right. The same behavior.
λoλcat
@catostrophe
Thanks, reading...