在Task <T>完成之前，正确暂停协程的方法

Question

I've recently dove into Kotlin coroutines Since I use a lot of Google's libraries, most of the jobs is done inside Task class

Currently I'm using this extension to suspend coroutine

suspend fun <T> awaitTask(task: Task<T>): T = suspendCoroutine { continuation ->
    task.addOnCompleteListener { task ->
        if (task.isSuccessful) {
            continuation.resume(task.result)
        } else {
            continuation.resumeWithException(task.exception!!)
        }
    }
}

But recently I've seen usage like this

suspend fun <T> awaitTask(task: Task<T>): T = suspendCoroutine { continuation ->
    try {
        val result = Tasks.await(task)
        continuation.resume(result)
    } catch (e: Exception) {
        continuation.resumeWithException(e)
    }
}

Is there any difference, and which one is correct?

UPD: second example isn't working, idk why

Answer 1

The block of code passed to suspendCoroutine { ... } should not block a thread that it is being invoked on, allowing the coroutine to be suspended. This way, the actual thread can be used for other tasks. This is a key feature that allows Kotlin coroutines to scale and to run multiple coroutines even on the single UI thread.

The first example does it correctly, because it invokes task.addOnCompleteListener (see docs) (which just adds a listener and returns immediately. That is why the first one works properly.

The second example uses Tasks.await(task) (see docs) which blocks the thread that it is being invoked on and does not return until the task is complete, so it does not allow coroutine to be properly suspended.

Answer 2

Your second example is a more traditional Blocking function.

In the world of typical Java multithreading, you use a function like that to block a thread until the result comes back.

Also in typical Java, there is a newer paradigm called Reactive programming, which allows you to avoid blocking the thread until the result comes back. Instead of just waiting for the result, you supply a first-class function to be executed whenever the result arrives. That way, there isn't a thread left on pause; instead, there's just a new event attached to the thread running the long operation, and when the operation is completed, that event will fire.

Blocking:

Thread one:  --* . . . ./---
Thread two:     \------*

Reactive:

Thread one: --*   (now free)
Thread two:    \-------*---

If you research Reactive Programming, you'll find much better explanations that go into a lot of depth.

Back to your question, though, these two ways of doing seemingly the same thing are a result of that paradigm shift from the Java world. Of course, since we're working with Coroutines here, we don't have to worry about that blocking problem at all ; the language takes care of it by suspending instead of blocking. So, a lot of the advantage of programming reactively is absolved on the langage level.

However , the paradigm still has its merits, so it would make sense to see people continuing to work in that pattern even when it's not as strictly necessary as elsewhere.