Besides Bill's great <blog post> about the danger around `runBlocking`, are there other deep dives a...

# coroutines

[leandro]

Besides Bill's great blog post about the danger around runBlocking, are there other deep dives and advanced explanations of it?

[CLOVIS]

Are you searching for specific information? The basic rule is simple: just don't use it in production code

[Robert Williams]

Don't think there's much to deep dive TBH - everything in this article is a problem with running any blocking code in a coroutine

[Robert Williams]

runBlocking just turns a coroutine into a blocking method which is exactly what it's documented to do

[Robert Williams]

If you think of everything under the runBlocking as a black box (which is how e.g. Java will treat it) there's nothing special or specially bad about it other than the fact that it's a blocking method

[CLOVIS]

there's nothing special or specially bad about it other than the fact that it's a blocking method

That's true, but in the real world if you see two suspending functions that call each other, you expect them to behave as structured concurrency describes. If there's a runBlocking between them though, they won't, and it's not always easy to find where it is.

I agree that it's exactly the same issue, but it's much harder to debug because you won't see it coming

[CLOVIS]

W.r.t the original article, I really dislike the runInterruptible example. It's really a hack, it shouldn't really appear in real codebases.

[Robert Williams]

Yeah, definitely should be used carefully and good coding and naming practices can help here (which I think was the point of the article)

[Robert Williams]

But the blanket "runBlocking is bad" manages to ignore the fact that it can be useful (particularly for Java interop) and ignores the actual blocking problem (which is also a problem for most of the code we use withContext for)

[simon.vergauwen]

@CLOVIS I'm not sure about that there are some good reasons to use runInterruptible though, but not sure about Android.

When building JVM applications, or servers, I've had to interact with some older Java SDKs from time to time and using runInterruptible in those cases is absolutely fine IMO.

[simon.vergauwen]

It's important to call runInterruptible with the right dispatcher though

[CLOVIS]

True, but the given example with runInterruptible { Thread.sleep() } is definitely not a good idea

[Stylianos Gakis]

It’s important to call runInterruptible with the right dispatcher though

And what would that be? I don’t think I’ve heard about this before

[CLOVIS]

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/run-interruptible.html

[Stylianos Gakis]

Oh sorry, I should’ve asked “Which Dispatcher is the right dispatcher to run runInterruptible on?“. And I suppose this question also asks indirectly “Which Dispatcher is a wrong dispatcher to do this in comparison?”

[CLOVIS]

I believe the correct dispatcher would be IO, since that's the only one made specifically to handle blocking calls

[CLOVIS]

Since, well, it blocks the thread, you wouldn't be able to use runInterruptible(Dispatchers.Main) { … }