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

What is “safe for production”?

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

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

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.

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

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

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

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