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
Gavin Bisesi
@Daenyth
wouldn't compile without it actually
Daniel Ochoa Rodríguez
@tzimisce012
yes yes, my mistake
sorry
:+1:
Gavin Bisesi
@Daenyth
necessary and correct*
tobymiller
@tobymiller
https://typelevel.org/cats-effect/datatypes/io.html#fromfuture says to do it like that. I think if there weren't an IO inside then it wouldn't be able to run it lazily
Gavin Bisesi
@Daenyth
The reason is that creating an object of Future is a side effect
tobymiller
@tobymiller
(and therefore it doesn't compile)
Gavin Bisesi
@Daenyth
it submits a runnable to a thread pool immediately
so it gets wrapped in delay
tobymiller
@tobymiller
I wonder if I'm doing something wrong by not disposing the (java) client that I'm using to make the async calls - could something like that be holding the process open?
Gavin Bisesi
@Daenyth
oh definitely
tobymiller
@tobymiller
my instinct says that if I write a snippet that just uses an in-process java future then it will work fine :P
Gavin Bisesi
@Daenyth
if it constructs a thread pool internally that has the isDaemon flag set a way on threads
I forget which way is which
tobymiller
@tobymiller
cool, I'll look into that then
thanks
Gavin Bisesi
@Daenyth
but one setting of that boolean will prevent the jvm from exiting until the threads do
Have a look at Resource.make, it'll help you wrap things with a lifecycle
you can connect with jvisualvm
tobymiller
@tobymiller
thanks!
Gavin Bisesi
@Daenyth
and just peek at the jvm as well
should tell you
ruslan
@unoexperto

Guys, is there example how to work with cancelable IO other than one in documentation? I cannot decipher it unfortunately. Here is what I want to achieve. I run synchronous DB query inside IO. I want to let user of this IO cancel query on timeout. For that I need to call java.sql.Statement.cancel() on statement that is used inside IO. How can I do that ?

I looked at IO.runCancelable and simply cannot understand how to use given SyncIO[CancelToken[IO]] and how to link it with suspended action of parent IO. Please advise.

Gavin Bisesi
@Daenyth
@rus try io.onCancellation or io.guaranteeCase
it's much simpler to use bracket semantics
well
if you go down that road you end up implementing doobie anyway..
aside..
ruslan
@unoexperto
@Daenyth Well, doobie doesn't support cancelation yet, unless I'm missing the news :)
Gavin Bisesi
@Daenyth
Has anyone seen IO/Async fromFuture be a source of contention or reduced throughput?
@rus right but you'd be better to add it than to start from scratch. You can use doobie's low-level api which just wraps jdbc one for one in IO
Haris Khan
@tyrantkhan
using Async.fromFuture, haven’t noticed any issues personally.
Gavin Bisesi
@Daenyth
We're observing some throughput issues that coincide with a release where we switched from monix-catnap's FutureLift to Async.fromFuture
and reading the implementation, I wonder if the difference is in the future.value call that cats makes
monix just uses future.onComplete
whereas cats checks preemptively if the future you gave it is already done
I haven't proved that it's from the fromFuture change, I'm just trying to rule out suspects
Haris Khan
@tyrantkhan
honestly the best way to do that might be from a closed off example code and doing some analysis on throughput using the two different implementations
only way you’ll know for sure.
Gavin Bisesi
@Daenyth
That won't be for sure
that will just prove that in my benchmark scenario one is faster
it doesn't prove that my benchmark code matches the real use
Haris Khan
@tyrantkhan
well, that’s also true.
ruslan
@unoexperto
@Daenyth IO in my version of cats doesn't have .onCancellation function.
Gavin Bisesi
@Daenyth
it comes from the Concurrent typeclass iirc, you need ContextShift[IO] + import cats.effect.implicits._
might have misworded the name, tab complete it
Piotr Gawryś
@Avasil
I think it's onCanceland it's just a syntax sugar for guaranteeCase
Haris Khan
@tyrantkhan
@Daenyth iif you do confirm Async.fromFuture is your root cause, do you mind letting me know, i might have to reevaluate our use of it , if its the case.
Gavin Bisesi
@Daenyth
I'll update if I do hit that. But note that IO.fromFuture is implemented exactly the same way