Hi everyone! In Kotlin Coroutines, if I have a fun...

# coroutines

[Guilherme Lima Pereira]

Hi everyone! In Kotlin Coroutines, if I have a function that returns a Deferred, launched on MainScope , should I be able to await until it finishes? I mean, should it block the Main Thread (that’s my goal, even though it sounds weird)?

[Tijl]

it will not block the main thread

[Tijl]

await is a suspending function

[Guilherme Lima Pereira]

thanks!

[Guilherme Lima Pereira]

I’m looking for a way to achieve that. I’m creating a public function and I’d give the option for the consumer to consume it sync or async

[Tijl]

wrap it in runBlocking

[Guilherme Lima Pereira]

That may work, I’ll try it! Thanks for the help 🙋

[Tijl]

maybe good to point out that if you make a suspending API consumers can also just do this themselves.

but if you want to provide a non-suspending API it’s an option. I just hope it won’t be blocking the main thread on my phone 😄

[Guilherme Lima Pereira]

We’re trying to work with a timeout. The idea is to block by 800ms and then release the thread, but without stopping the execution.

Kinda crazy, but we want to avoid crashing because of third party sdks 😕

[ephemient]

n.b. do not use runBlocking on main thread https://github.com/Kotlin/kotlinx.coroutines/issues/2448

[ephemient]

if it's on some other thread that doesn't belong to any coroutine dispatcher you should be ok

[ephemient]

(but as a corollary, don't runBlocking from inside anything that suspends, either)

[Guilherme Lima Pereira]

I’m heading to this kind of implementation:

runBlocking {
    Log.d("GLP", "Started runBlocking")
    val result = withTimeoutOrNull(2_100) {
        Log.d("GLP", "Started withTimeoutOrNull")
        envVar.fetch().join()
        Log.d("GLP", "Finished withTimeoutOrNull")
    }

    if (result == null) {
        Log.d("GLP", "Reached timeout")
    }

    Log.d("GLP", "Finished runBlocking")
}

[Guilherme Lima Pereira]

where envVar.fetch() returns a Deferred<Unit> (from a async call)

[Guilherme Lima Pereira]

this way I won’t cancel the execution, but I won’t block the main thread until the execution finishes, but until it reaches the timeout (2100ms in this test scenario)

[Tijl]

blocking the main thread is still very bad, even if it’s for 2100ms.

that said using runBlocking on the main thread works just fine, only runBlocking (Dispatchers.Main on the main thread is problematic

[ephemient]

runBlocking on the main thead... how sure are you that nothing you directly or indirectly call will want to switch context to Dispatchers.Main?

[Tijl]

that goes for any Dispatcher and runBlocking

[Tijl]

Incidentally using Dispatchers.Main.immidiate does work from inside runBlocking , e.g.

runBlocking { // called from Main
   withContext(Dispatchers.Main.immidiate) {
   }
}

I presume the same goes for other .immediate versions of Dispatchers

[ephemient]

yes, it does. the biggest difference is that you're not scheduling any other code on the IO pool's threads, so a simple "don't use runBlocking if you might be called from a suspend context" rule is enough, but everybody has access to Main

[ephemient]

anyhow, using runBlocking or not, 2100ms is extremely long for the main thread to be blocked. that's 126000 dropped frames on most devices, and within a small factor of being killed by ANR too

[Tijl]

Sometimes you can’t go around using runBlocking, even from a suspended context. E.g. inside init{} or lazy{} or get/set . Of course you should know what the code you call is doing but I think that rule generally should apply.

For this reason, I hope they make immediate usable from runBlocking , it’s only a lack of implementation this does not work right now.

[ephemient]

you can get around them, by not doing the work in the constructor or not using properties. but it would be nice to have lazy properties and delegates.

[dewildte]

What are you actually trying to achieve.

[Tijl]

Not doing initialisation in the constructor (if there’s no functional reason not to) is an anti-pattern, it’ll introduce an additional state for your class which is a source of bugs. That said, it can usually be solved by suspending “Constructor functions”, it’s true that is often better than using runBlocking.

Still saying “be careful with using runBlocking, because it will block your thread” is better than “don’t use runBlocking if you might be called from a suspend context”. It simply goes waaay too far in my opinion. Especially the maybe there, but even then.

Essentially coroutines have a dual purpose, they provide suspending functions, but they also are context scheduler. I end up using runBlocking here and there to schedule work in the correct context, rather than doing a suspended wait for some long running task.

[ephemient]

I thought about it, but in the end I disagree. I've had to track down far too many issues in a large codebase where runBlocking did work at some point, but unrelated changes exposed deadlocks. It is a far better use of everyone's time to forbid runBlocking from anything in the call chain from a suspending function.

[Guilherme Lima Pereira]

Hey everyone, sorry for the confusion about how much time the blocking would last. In fact, it’ll be only 850ms and not 2100ms.

@dewildte we created an internal SDK that returns a map. The goal of this map is to allow not initializing some SDK we know it’s crashing (e.g. what happened with Facebook). This map comes from a server and it should be fast (everything was optimized on it on server side, latency, cache, etc), but we won’t trust it, that’s why we’re putting an 850ms withTimeout block.

Why runBlocking?
I want to block the app initialization (Application class) until the fetch timeout. In the happy path, we would be able to not call the initialize function of some libraries we’ve wrapped.

Does it make sense for you? Please, share your sincere opinion 😄

[Guilherme Lima Pereira]

We don’t have any runBlocking call on our project, we’ve talked about it and it didn’t make sense until now.

I’d be very happy if you have any idea on how implement it without runBlocking

[dewildte]

Perhaps make a splash screen and do not navigate to the next screen until you have the data required to do your work. The main point here is to never block the main thread because it locks up the entire UI. The goal is to communicate work in progress in other ways but never block the main thread.

[dewildte]

https://developer.android.com/jetpack/guide?authuser=1#addendum

[Guilherme Lima Pereira]

Many libraries needs to be initialized on the Application , so dealing with it on a Splash screen won’t work for me, I think…

[Tijl]

just put your minSdkVersion to Android 12 android dancehttps://developer.android.com/about/versions/12/features/splash-screen

[ephemient]

850ms is still ridiculously long to hang the main thread for. if it's in Application create, there's no UI yet - so you're not missing any frames, but it's also terrible, it'll prevent the UI from appearing (such as splash screen)

[ephemient]

facebook sdk shouldn't require being loaded in application. what other sdks are you concerned about?

[Guilherme Lima Pereira]

@ephemient for now we’re going with runBlocking (dealine x time to refactor) but your question was very important. I thought about it and I’ll organize a project to move some initializations to the first activity and then I can run things in parallel in there, without blocking the thread

[Tijl]

be aware that on Android any activity can be your “first activity”

[Guilherme Lima Pereira]

Our project only has one activity 🙌