Support ConcurrentEffect on Rerunnable

[oscar-stripe]

see: https://github.com/twitter/util/blob/develop/util-core/src/main/scala/com/twitter/util/Future.scala#L1496

I think this is possible, but a bit of work. Could be useful for a few cases I can think of at Stripe.

[travisbrown]

Yes, I started this today but decided to put it off for this release, to unblock Finch. It should probably be non-implicit and parameterized on a FuturePool.

[Horneth]

Would be quite interested in this as well, to use in fs2 for instance

[felixbr]

A little update here: For the past month I've been working on and off on the Concurrent[Rerunnable] instance (Effect[Rerunnable] already exists). There are still 8 test-cases failing (all related to cancelation) and the implementation is still kinda messy. I have to admit that it's really hard to get cancelation right the way cats-effect demands it.

So don't expect a complete solution soon but if someone's planning to work on it (or already has), you might want to let me know 🙂

[zachkirlew]

Interested

[felixbr]

Thanks for showing interest for this thing. Here's a quick update since I've last hacked on it:

I've got an implementation working that "only" has 8-9 failing test-cases and all of them are concerned with cancelation. Unfortunately cancelation is pretty difficult and the underlying Future is eager, which makes it even more difficult to satisfy all the laws around Concurrent.

I studied how cats.effect.IO and monix.eval.Task implement cancelation and they do it with a separate stack for the bookkeeping of cancelations. I haven't gotten this working with Future and Rerunnable yet as Rerunnable has nothing like that currently, so it requires quite a bit of refactoring.

To be honest, I don't know if I can finish the implementation as it is right now, as part way through it almost seemed impossible. It probably is possible, but I'm not sure if I personally can do it.

Now, you might be thinking "cancelation isn't that important to me, can't we do without it?". Unfortunately Concurrent directly mandates cancelation (other than Effect). To get ConcurrentEffect you need both.

I don't think releasing an unlawful instance for Concurrent is something I'm willing to risk either, as it's hard to say what people are going to do with it. And even though you might not use cancelation explicitly in your code it can still come up for resource-safety abstractions like Resource and Bracket.

Daniel Spiewak and others are already working on cats-effect 3.0, which will restructure the typeclass hierarchy significantly. I don't know the exact timeline yet but I currently lean somewhat on the side of waiting for a release-candidate and attempt to implement that instead, if it's going to happen in the next months. With a bit of luck cats-effect 3.0 will be easier to implement for Rerunnable and might be more modular to choose what we need.

tl;dr Sorry for the bad news 😐

[felixbr]

Update: I tried cats-effect 3.0.0-M2 typeclasses with Rerunnable. Cancelation is still a big issue.

See the draft here: #267