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
Rohde Fischer
@rfftrifork
@SystemFw not really :/ I'm halfway guessing that's the cause from the way you ask
Fabio Labella
@SystemFw
yeah
depending on your point of view, it's debatable which one of the two examples is puzzling
think about it: start means that you return control immediately, and one fiber keeps going while another is spawn asynchronously
so you have producer.start >> consumer.start >> IO(println("when does this happen"))
the third statement should execute pretty much immediately
which means that the whole application should shut down immediately
does that view point make sense? (as in, do you see how that's coherent, if not correct)
Rohde Fischer
@rfftrifork
because Fibers aren't threads?
Fabio Labella
@SystemFw
no, you can have the same concept with real threads
Rohde Fischer
@rfftrifork
where you start two threads and it still terminates?
Fabio Labella
@SystemFw
Thread1.start(); Thread2.start(), println("when does this happen")
wait, we're getting to what actually happens
but do you see why that semantics is coherent?
start means "spawn something and keep going without waiting for it"
that's the whole point of it actually
so if you start, start, end
end will happen without waiting for the two started things to finish
Rohde Fischer
@rfftrifork
ah I see the coherency now, yes
Fabio Labella
@SystemFw
right, another viewpoint is
if some things have started, I don't want to shut down until they are done
(this is the behaviour you were expecting)
that also makes sense right?
Rohde Fischer
@rfftrifork
indeed
Fabio Labella
@SystemFw
whether a thread behaves in the first manner or the second is called daemonicity
well, as in, daemon threads do not prevent the JVM from shutting down
non daemon threads do
Rohde Fischer
@rfftrifork
yes, so to rephrase, it's basically a matter if I expected to wait for all child threads or if I expect it not to
Fabio Labella
@SystemFw
yeah
you can rephrase your question as "does the thread pool in IOApp have daemon or not?"
and the answer is no, which is why you see what you see
if you look up the relevant issues you will find the debate as to why that was chosen
it is indeed debatable
Rohde Fischer
@rfftrifork
as almost all things in programming :)
Fabio Labella
@SystemFw
anyway, you can join your fibers are the end to actually wait for them in the cats-effect realm, without knowing about threads
this concept (of not losing spawned concurrent processes) leads to a safer model of concurrency, and it's supported by e.g. fs2 concurrently
you can build it on top of a "lossy" model like cats-effect, which acts like a primitive
gtg now, hopefully it sheds some clarity
Rohde Fischer
@rfftrifork
a lot more than 10 minutes ago definitely, thanks a lot
Rohde Fischer
@rfftrifork
per the talk of daemon threads vs. non-daemon yesterday, I was actually wondering, would it be sound to always to join if I expect them to be non-daemon, so I can keep the code independent on which ExecutionContext is in use?
Paul Snively
@paul-snively
I prefer to always join if that's the desired behavior.
Rohde Fischer
@rfftrifork
@paul-snively (y)
Torsten Schmits
@tek
do you guys let timers run on the global EC?
Gavin Bisesi
@Daenyth
When we were migrating from App to IOApp we used the same pool that backed our ContextShift for the Timer. With IOApp it has its own ScheduledExecutorService
We didn't observe any issues from it
You probably don't want to use global for anything, ideally
Torsten Schmits
@tek
does a timer permanently occupy a thread?
Gavin Bisesi
@Daenyth
No, nothing in cats-effect does
You can run a whole concurrent app on one thread
Everything is nonblocking (at the thread level)