CancelableFuture

[fsvehla]

Closes #1627

Delegates calls to a Future that it wraps. I’ve found a lightweight way to support Scala 2.11 as well.

[iravid]

Seeing that that this is an impure construct meant mainly for interop with Future-based programs, it appears that cancel would be more useful as an impure operation.

[iravid]

I'm also wondering about cancel returning the Exit[E, A], and about E appearing at all in the trait.

[fsvehla]

My initial idea was def cancel: Unit and no E in the trait (see some discussion on the original ticket).

Since we return the CancelableFuture also from Fiber / Zio, I wouldn’t know how to get a Runtime to run the cancellation action with. We also couldn’t use it under Scala.JS.

[iravid]

You can access the runtime at any point using ZIO.runtime[R]. But Scala.JS is a good point. Maybe we should only offer asynchronous cancellation?

[fsvehla]

In order to run the UIO[Future] returned from toFuture a runtime must be available anyway at the call site.

About ZIO.runtime - I still wouldn’t be able to return a synchronous result because it returns a UIO[Runtime] – am I missing something?

[iravid]

@fsvehla

final def toFutureWith(f: E => Throwable): UIO[CancelableFuture[E, A]] = 
  ZIO.runtime[Any].flatMap { runtime =>
    // construct CancelableFuture here, using the runtime
  }

[fsvehla]

test_212_jdk11_jvm failure is unrelated.

[jdegoes]

Love the new ZIO Test!

[fsvehla]

@iravid I’ve understood now – it didn’t occur to me to refer to the Runtime when it is created.

[dpennell]

Is there anything I can do to help with this?

[fsvehla]

It will be ready soon. I am at the hackathon and will wrap it up tomorrow

[dpennell]

@fsvehla I'm jealous - wish I could be there!

[fsvehla]

addressed all comments.

[jdegoes]

This is only used in Cancelable, right? In that case, I'd inline it completely so we can delete the class.

[fsvehla]

@jdegoes You were actually correct, there is java.util.Cancelable

def cancel(mayInterruptIfRunning: Boolean): Boolean
def isCancelled(): Boolean
def isDone(): Boolean

Let’s use that.

[fsvehla]

That JCP was never accepted,

[fsvehla]

Inlined.

[neko-kai]

Maybe this could return another Future instead of blocking the current thread?

[fsvehla]

I have no strong opinion here, but see
#1655 (comment)

[neko-kai]

Well, if we go back to the original use case:

We've started introducing zio at the edges of our system. This results in having multiple unsafeRunToFutures running in different actors. I'm looking for advice on terminating these from outside of zio (e.g. when the parent actor is shutting down).

I'm fairly sure introducing a potentially never-ending blocking operation inside an akka actor is a big no-no. Note that Future/scala.Promise is also impure and it's already running the moment it's returned, so it's no less ergonomic to use it in impure code. In fact, I'd expect that most users will not care about the Exit return AND might not want to wait until the fiber is interrupted, in which case the default run-and-forget behavior of cancel without Await is preferrable.

Note that there would be no way for a user to achieve run-and-forget without blocking a thread if we commit to a synchronous API.

[fsvehla]

👍, Kai. My initial idea was to return an UIO[Exit[E, A]], because the runtime would have been around anyway at the call site where the CancelableFuture is created. Returning a Future sounds like a good compromise

[neko-kai]

We might want to make it public so that users can use the additional cancellation ability!

[fsvehla]

Addressed comments

[neko-kai]

👍

[neko-kai]

I wonder if type annotations could be avoided if concurrent.Promise[A] is used in success/failure returns instead of p.type

[jdegoes]

@fsvehla Thank you for all your work on this feature, and congratulations on your first ZIO contribution!

[dpennell]

ZIO team - thanks for addressing this!