the `CompletableDeferred` was completely internal,...

# coroutines

[bj0]

the CompletableDeferred was completely internal, I was using return deferred.await() and object.onCallback {deferred.complete(it)}

[dave08]

See https://github.com/Kotlin/kotlinx.coroutines/issues/218 , I think that this point is currently very unclear in the docs... but I don't think that is proper use of CompleableDeferred... I think what you need is invokeOnCompletion and check the`isCancelled` property on the CancellableContinuation provided... see https://github.com/Kotlin/kotlinx.coroutines/blob/master/core/kotlinx-coroutines-core/src/main/kotlin/kotlinx/coroutines/experimental/CancellableContinuation.kt

[dave08]

Then a Future being converted over can call cancel over there...

[bj0]

I was trying to find a better way than to use CompletableDeferred, but I don't see what invokeOnCompletion has to do with it. Using a Future is effectively the same thing as using a CompletableDeferred

[dave08]

I mean inside the suspendCancellableCoroutine, it gets completed when it's cancelled, so if you put that listener in there and check if themreason why it was completed was cancellation, you could handle the side effects such as cancelling your future.

But all this is assuming that I understand what your trying to accomplish... I thought you were trying to adapt an api that currently returns a regular Future or callback into a suspendable api. That is what all this is for... but a good example of when a CompletableDeferred is used in such adapters is like in retrofit, where theres no choice but to return a Deferred, since the interfaces get implemented by retrofit... like in Jake Wharton's adapter... but there you actually want the Deferred and not to hide it...

[bj0]

Ah yea I wasn't interested in why it was canceled, I was interested in cancelling it from the outside. I'm turning a callback into a coroutine, something like this:

var deferred: CompletableDeferred<Item>? = null
    
    suspend fun getItem(): Item {
        deferred = CompletableDeferred<Item>
        someObject.onCallback { deferred.complete(it) }
        return deferred!!.await()
    } 
    
    fun cancelGet() = deferred?.cancel() ?: false

[bj0]

that way the cancelGet can be called from another source (like a user hitting the back button)

[dave08]

Why dont you just run cancel on the Job from launch that you're running the suspend function in...?

[bj0]

It's not run from a launch, but another suspend fun

[bj0]

it's actually run from another use button click, there's nothing to cancel on that i'm explicitly creating

[dave08]

But in the end, you have to run a suspend from launch...

[dave08]

or from async or some other coroutine builder that you can cancel... it just doesn't make sense to cancel the suspend...

[bj0]

na, it's being run from something like this: https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/coroutines-guide-ui.md#at-most-one-concurrent-job

[dave08]

why do you need to cancel it?

[bj0]

it's waiting on user input, but they can cancel it by clicking the back button

[dave08]

So launch it from there and save the Job for it to be cancelled

[bj0]

I eventually figured out I could just use the continuation like this:

var activeCont: CancellableContinuation<Item>? = null


    suspend fun getItem() = suspendCancellableCoroutine<Item> { cont ->
        someObject.onCallback { cont.complete(it) }
        activeCont = cont
    }

    fun cancelGet() = activeCont?.cancel() ?: false

[bj0]

that just moves the creation/cancel of the 'job' from one class to the other, I don't really see a difference

[dave08]

No, a suspendCoroutine fun is just a declaration of what to do when it suspends and resumes... the actual running of it is inside the coroutine builder like launch... even an actor is running inside a job, otherwise you wouldnt be able to run the suspend function in the first place...

[dave08]

For example I have an adapter for xmlrpc:

class XmlRpcCoroutineClientImpl(override val client: XmlRpcClient): XmlRpcCoroutineClient {
	override suspend fun <T> awaitExecute(pRequest: XmlRpcRequest): T? =
			suspendCancellableCoroutine {
				client.executeAsync(pRequest, object: AsyncCallback {
					override fun handleResult(pRequest: XmlRpcRequest?, pResult: Any) {
						<http://logger.info|logger.info>("Request '$pRequest' succeeded: {}", pResult.toString())

						it.resume(pResult as? T)
					}

					override fun handleError(pRequest: XmlRpcRequest?, pError: Throwable) {
						logger.error("Request '$pRequest' failed: ", pError)

						it.resumeWithException(pError)
					}

				})
			}
}

[dave08]

In my api I use it to run requests w/ different params: xmlRpcClient.awaitExecutes(it, Array<Any>::class.java)

[dave08]

But I run it in a launch...

[dave08]

suspendCoroutine is just used for adapting callback based api for use in coroutines...

[bj0]

I know that, but as you saw, in my case it's run from an actor so there's no explicit launch job

[bj0]

what I'm doing with the continuation does work, and it seems cleaner and more self-contained than wrapping things in an extra launch at the callsite

[dave08]

But that's just reinventing the wheel... but you choose... 😉

[bj0]

what do you mean? I think any other way of doing it would require even more code/work

[dave08]

var currItemGetterJob: Job? = null
// In the actor, simplified...
currItemGetterJob = launch { getItem() }
// In cancel button handler
currItemGetterJob.cancel()

Just make sure that you don't accidentally assign a new job before cancelling the old one...

[bj0]

right, what I'm saying is that's not really much different than what I was doing before, it just moves the job creation from where getItem is to the callsite. And in my case the android back button is actually handled in a parent class so it would be more difficult. Plus, if I use the continuation for cancellation like in that last snippet I posted, than I don't have to create any extra jobs, it just cancels the calling scope (as if I just threw CancellationException at the callsite)

[dave08]

So just fun getItem() = async {} then await for the deferred or cancel it... I think that you're using internal api to do end user work... you might run into pitfalls that were already taken care of for you... you can run 10000 launches and its still very light...

[bj0]

I think I'm using it for what it was created for (wrapping callbacks), I just have an unusual setup with the cancellation callback coming from a different source. I know callbacks are lightweight, I'm mostly concerned about keeping the code clean and small. I also don't have to worry about multiple calls, there can only be a single "get" active at a time, so the way I'm doing it with continuations should be fine

[bj0]

anyway, I think the way I'm doing it makes the most sense for my use-case. I'm effectively wrapping 2 callbacks with a suspendCancellableCoroutine, one callback just happens to signal cancellation through an external function call.