Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:03
    tkawachi commented #2139
  • 12:43
    tkawachi commented #2139
  • 12:04
    bjornregnell commented #2140
  • 12:04
    bjornregnell commented #2140
  • 11:58
    bjornregnell commented #2140
  • Jul 24 15:02
    SethTisue synchronize #2140
  • Jul 24 14:46
    SethTisue synchronize #2140
  • Jul 24 14:38
    SethTisue commented #2140
  • Jul 24 14:37
    SethTisue opened #2140
  • Jul 24 13:51
    jxnu-liguobin synchronize #9706
  • Jul 24 13:49
    jxnu-liguobin synchronize #9706
  • Jul 24 13:30
    SethTisue commented #2139
  • Jul 24 13:30
    SethTisue commented #2139
  • Jul 24 11:19
    bishabosha assigned #2138
  • Jul 24 11:19
    bishabosha review_requested #2138
  • Jul 24 08:14
    dwijnand commented #12314
  • Jul 24 06:46
    tkawachi opened #2139
  • Jul 24 06:37
    tkawachi edited #2138
  • Jul 24 04:34
    scala-jenkins milestoned #9709
  • Jul 24 04:34
    som-snytt opened #9709
Matthew Pickering
@mpickering
thanks, useful to know
looks like there's lots of useful scala plugins
srimugunthan
@srimugunthan
whats the best way to cancel a future in scala?
Josh
@joshlemer
you cant cancel a future in general
Martijn Hoekstra
@martijnhoekstra
scala Future has no facilities for cancellation
Gavin Bisesi
@Daenyth
There are other task abstractions that support it, like cats-effect, but they're a bit different and you'd need to adapt some bits
trepidacious
@trepidacious
Does any equivalent of Future have a non-cooperative cancellation feature? I mean one that doesn't rely on the code in the Future having some kind of polling for cancellation?
Martijn Hoekstra
@martijnhoekstra
You can build an API on top that cancels at flatMap boundaries
Derek Wickern
@dwickern
you can cancel between each continuation... otherwise you would need cooperation
trepidacious
@trepidacious
Yup if the contents are interpreted
I've not looked into continuations
Derek Wickern
@dwickern
it would help if you have low-level cancellable primitives
like an http client with cancellable requests
trepidacious
@trepidacious
Yes
Derek Wickern
@dwickern
and a cancellable traverse, etc
trepidacious
@trepidacious
It's funny that the even on a VM there isn't a safe way to stop a thread or something like a thread
Martijn Hoekstra
@martijnhoekstra
you will probably always need cooperation
Seth Tisue
@SethTisue

whats the best way to cancel a future in scala?

relevant: https://viktorklang.com/blog/Futures-in-Scala-protips-6.html

Fabio Labella
@SystemFw

@trepidacious

or something like a thread

Depends on what you consider "something like a thread"

a cats-effect Fiber can be interrupted
although obviously you are still limited by the JVM, i.e. if you build your stuff as F.delay { huge block } you still can't do much about it
trepidacious
@trepidacious
@SystemFw Ah that's cool, I'll have a look. I was thinking about the huge block case - I guess if the block is pure, it should theoretically be possible to just stop it dead without problems, but there's no actual way of doing that?
Martijn Hoekstra
@martijnhoekstra
if the block is pure, it should theoretically be possible to just stop it dead
it's very difficult to define what "it" is in that sentence
Fabio Labella
@SystemFw
very fine grained interruption needs fine grained control of evaluation as well
for example the Haskell runtime uses the points in which the code yields to the garbage collector (which happens often due to the interaction with laziness) as yield points for concurrency as well
once you start thinking about interruption from an implementor point of view
which we had to do a lot in cats-effect
you'll see that "just stop it" is one of the those things that seems very straightforward on paper, but that it isn't at all
Josh
@joshlemer
Did you guys look at "pull-based" futures that Rust has?
Fabio Labella
@SystemFw
any link?
the implementation of interruption in cats-effect currently checks the interrupt flag at async boundaries
which are introduced by several operations
Marcin Sokrates
@marcinsokrates_twitter
Turning asynchronous OS signals into exceptions is possible, you can do it in C++/GCC, the JVM does it for NPEs I think, but I'm sure there are lots of things to consider while doing that
Fabio Labella
@SystemFw
there's also another whole bunch of complexity that comes with the interaction with resource safety and finalisers
Josh
@joshlemer
hmm having trouble finding a good article
Fabio Labella
@SystemFw
but that being said, both fs2 and cats-effect, and Monix ( as well as Twitter futures iirc) are cancelable
Josh
@joshlemer
Basically, Rust futures are pull- (aka poll-) based not push-based, which means that to cancel it, children just have to stop polling their parents
Fabio Labella
@SystemFw
I'm not sure how exactly that maps to IO and/or Stream (Streamis pull-based for example)
I think IO will map to pull-based as well
trepidacious
@trepidacious
@SystemFw @martijnhoekstra Yes, it's pretty clear it's one of those areas where a lot of complexity is covered up by a short description :)
Fabio Labella
@SystemFw
@joshlemer one immediate question for example is deciding when do you want to check the interrupt flag
trepidacious
@trepidacious
@SystemFw @martijnhoekstra Makes me think of real-time C where you handle these things in processor interrupts to be able to do non-cooperative threading, I have no idea what the VM equivalent of that is. I guess there is also a pretty significant tradeoff between latency and throughput.
Fabio Labella
@SystemFw
if you're interested I'd read about how Haskell does it. The fact the runtime controls both evaluation of pure code as well as IO and concurrency means you have a lot more control about what you can do
srimugunthan
@srimugunthan
trepidacious
@trepidacious
@SystemFw I should stop being surprised when it turns out Haskell does something more elegantly :)
Maybe I'll use it one day :)
Marcin Sokrates
@marcinsokrates_twitter
Oh, the JVM actually has Thread.stop(), but they deprecated it for fear of inconsistent state in interrupted lock-protected code sections
trepidacious
@trepidacious
@marcinsokrates_twitter Yes that's what I was thinking of. Maybe if you have pure code that definitely doesn't use locks you could use it... ;)
Marcin Sokrates
@marcinsokrates_twitter
I wish they just added a mechanism for suspending interrupts in critical sections instead