Is `runBlocking` safe for production if we have helper suspended functions, and are using an interfa...

# coroutines

[Allan Wang]

Is runBlocking safe for production if we have helper suspended functions, and are using an interface where it’s okay to block the thread?

For instance, I’m building a notification widget, which requires updates to be done in onDataSetChanged, before the provider will apply the data

[gildor]

What is “safe for production”?

[gildor]

In most cases it’s possible to avoid use runBlocking

[gildor]

and it’s really rare in real code

[Allan Wang]

Well say you have a function

suspend fun loadData(): Data

which is suspended purely to ensure that it never gets called on the main thread.

You now want to use an interface containing

fun a()
fun b()

where you must load the data in a. Internally, b must execute after the data is loaded.

In this case we could make two copies of the data loading function, where one is suspended and one is not. I’m curious if that is necessary or if we can just wrap it in runBlocking

[gildor]

which is suspended purely to ensure that it never gets called on the main thread.

This is really strange case. Why do you need suspend function for this? suspend means that function is async

[gildor]

I think usage of runBlocking is possible of course, but error prone, if this function in future will change and it will be long operation your app will freeze

[gildor]

where you must load the data in a. Internally, b must execute after the data is loaded.

Still strange for me, can you show example.

[Allan Wang]

Is it not a common pattern to specify suspend purely to ensure thread values?

I have a bunch of helper functions that by themselves are not suspend functions. However, they need to execute on the main thread or in the background. Wrapping the logic with suspension makes it easier for the caller, since they no longer need to worry about managing context.

For now I’ve opted just to make a function for the non suspended version, then wrap it again for other use cases.

[gildor]

Is it not a common pattern to specify suspend purely to ensure thread values?

What exactly do you mean? To switch to main thread?

[gildor]

if so, yeas, it’s completely fine

[gildor]

but use runBlocking is dangerous, what if this function will add some network request, or delay or other long operations
This will be completely valid from function point of view, but runBlocking will just block thread completely in this case

[gildor]

To avoid this, just wrap it with launch, it will work for 99% cases

[serebit]

The only use I have for runBlocking in one of my libraries is to close resources on program exit in JVM code, since the runtime hook for program close is a thread and not a coroutine

[gildor]

Same for us, we use only on app creation and carefully, only for file io, and in some cases for resources cleanup