Kotlinx.coroutines: Fail-fast when trying to do `runBlocking` from Android UI thread

[elizarov]

Android UI thread does not generally allow blocking operations and vaiours things like doing network IO from UI thread throws an exception on Android. Similarly, using runBlocking from Android UI thread shall throw an exception to fail-fast and prevent hard-to-diagnose bugs when the code just "happens to run fast" during testing but can in fact hang the UI in production.

[Groostav]

Can I request this apply to JavaFX also?

[elizarov]

It indeed makes sense for all UI dispatchers.

[deva666]

@elizarov is this up for grabs? I'd be interested in working on this

[elizarov]

@deva666 You can try to work out solution. I have not though too deep about possible implementation strategies, so I don't know if it will turn out to be simple or not.

[jcornaz]

I have to say I like the Idea. But why only forbid runBlocking on UI threads? Blocking a thread of the fork-join-pool is also bad practice.

And actually, even if I like very much the Idea I have some fears about our usage. In our codebase we are slowly adding coroutines and improving our code base to block as less often as possible. But we have to live with an existing code base which has legacy code blocking the UI (without using coroutine). And problems arise when we convert some code or add new code using coroutines. Even if we try as much as possible to make the code not blocking the UI anymore, it is sometime to much work and we simply put the suspending code in runBlocking and create a refactoring issue for later. After all, the code under modification was already blocking the UI, and we cannot completely rewrite the application each time we add a small feature. And at the end, it is still nice to use runBlocking, because it makes it obvious that the code is blocking and that further refactoring is needed.

But if kotlinx.coroutines sudently start to throw exceptions when we use runBlocking in UI thread what should we do? Our code base is too massive to make it completely non-ui-blocking in a reasonable amount of time.

[qwwdfsad]

@jcornaz You raised an important issue, thank you

In general, blocking UI thread is a no go, so we prefer to have this check enabled by default.
But nevertheless, your problem is clear. Will system property which disables this feature be a good solution for you?

[jcornaz]

Will system property which disables this feature be a good solution for you?

Yes I thought about that too. It would be great.

[elizarov]

Shall we open a separate issue for a property, since this issue already sits on the release train and will be closed soon?

[elizarov]

@jcornaz See #458

[svenjacobs]

I have a bit of coroutine code that needs to be run in a blocking fashion when my Android application starts. For instance in my Application class I need to fetch a value from a suspending function. Based on the result of that value certain application options are configured. This should actually block because the configuration needs to be finished before/while the application starts. This worked well before version 0.24 and was not noticeable.

How do I solve this use case now?

[elizarov]

Let's discuss a solution in #464