I see that `CancellableContinuation.tryResume` is ...

# coroutines

[Edoardo Luppi]

I see that CancellableContinuation.tryResume is marked as internal API.
Have you ever had to use it?

I have a callback that might fire multiple times, but obviously the continuation must be resumed only once.
Does that look like a legitimate use case?

Note that I can't get rid of the callback, I still need it for future calls, I just don't want to resume obviously.

[Joffrey]

If you adapt a mutli-fire callback, you should probably use callbackFlow instead

[Edoardo Luppi]

I think my case is a bit more specific.
I subscribe to an error callback during a suspend fun connect call, to connect to a socket.

The error callback can be called instead of connected, if connection fails, but also afterwards for any network error, for example.

[Daniel Pitts]

Why are you storing continuations for the callback?

[Edoardo Luppi]

I'm not storing continuations. I'm subscribing to an event via a callback inside a suspendCancellableCoroutine block.

[Daniel Pitts]

Ah, and that event might be fired more than once, got it.

[Daniel Pitts]

The documentation for `suspendCancellableCoroutine`:

* Suspends the coroutine like [suspendCoroutine], but providing a [CancellableContinuation] to
 * the [block]. This function throws a [CancellationException] if the [Job] of the coroutine is
 * cancelled or completed while it is suspended.
 *
 * A typical use of this function is to suspend a coroutine while waiting for a result
 * from a single-shot callback API and to return the result to the caller.
 * For multi-shot callback APIs see [callbackFlow][kotlinx.coroutines.flow.callbackFlow].

[Edoardo Luppi]

But I can't use a Flow, for my use case it's not compatible with the API I want to expose.

[Daniel Pitts]

BTW, unrelated to your question but is this a JVM project?

[Edoardo Luppi]

Nope, I'm wrapping an internal JS library.

[Daniel Pitts]

What is the API signature you want to expose?

[Daniel Pitts]

You might be able to use a lazy for this:

fun callbackApi(callback: () -> Unit) {
    repeat(3) {
        callback()
    }
}

suspend fun connect() {
    suspendCancellableCoroutine {
        val once = lazy { it.resume(Unit) }
        callbackApi { once.value }
    }
}

[Rick Clephas]

Maybe try to split your code differently. If you turn your callback into a Flow you can await a single value in your suspend function.
Or alternatively keep a local state value to track if the callback was already fired (ignoring the callback in that case).

[Rick Clephas]

Depending on your code you could also introduce a new "connect callback" which is stored as a state value. Once used clear the value and your connect callback won't be called again.

Note: you might have to make sure your state value is thread safe

[Edoardo Luppi]

Ended up simply checking for the continuation status with continuation.isActive.
If it isn't active, it means it's been cancelled or completed already (normally or with an exception).

[Dmitry Khalanskiy [JB]]

Beware the parallelism: if you have several threads that can resume, and you have code like this

if (isActive) {
  // line X
  resume(Unit)
}

then the coroutine could have been resumed while this thread executes line X.

[Edoardo Luppi]

Luckily I'm on JS, so that's not an issue.
But if it was, would you suggest maintaining an atomic boolean state, or going with the tryResume calls?

[Dmitry Khalanskiy [JB]]

I'd recommend never using things marked with InternalCoroutinesApi unless we have your project in our CI. We can (and sometimes do) remove, rename, edit these API entry points with no concern for backward compatibility. tryResume is an implementation detail that may change at any point.

[Edoardo Luppi]

Btw, this is where I first learnt about try* functions.
https://github.com/Kotlin/kotlinx.coroutines/issues/48

Looks like I'm not alone in this kind of problem.

[Dmitry Khalanskiy [JB]]

I'm curious: is it guaranteed in your case that the continuation is resumed with exactly the same value (===) each time?

[Edoardo Luppi]

The thing is the continuation must be resumed exactly once with the error passed in to the callback.

All subsequent calls to the callback should not resume again, they should simply handle the error or forward it somewhere else.

[Edoardo Luppi]

But no, the (possible) error will be different each time

[Edoardo Luppi]

To be more clear, I might get a connection error because the TLS cert is invalid.
I resume with that error.

If I don't get an initial error, a follow up error might be a timeout, but that will be forwarded to another handler.

[Dmitry Khalanskiy [JB]]

Got it, thanks! Yes, I'd say an atomic boolean is the way to go here.