Daniil Ovchinnikov

It would be great to have `withoutContext(Key) {}`

> runBlocking has "blocking" in its name, so the idea is that it should be treated like any other blocking task. Then nested `runBlocking` should not steal tasks from the...

Let me describe an issue, which we've faced in IJ. Consider a platform API interface which is supposed to be implemented in 3rd-party plugins: ``` interface CoolExtension { fun computeStuff():...

> making runBlocking steal tasks is not unambiguously good Exactly! This and #3982 are the reasons #3439 (stealing inside `runBlocking`) does not work. I'm sure there are other reasons.

Let me elaborate on this first: https://github.com/Kotlin/kotlinx.coroutines/issues/3983#issuecomment-1852458333 Two things to consider: 1. `runBlocking` on a thread from a limited dispatcher may cause a starvation deadlock. ``` val d = Dispatchers.IO.limitedDispatcher(10)...

Re https://github.com/Kotlin/kotlinx.coroutines/issues/3983#issuecomment-1862601859 This approach would solve the starvation problem, because eventually there would be enough threads to handle all the tasks. But with this approach there will be no guarantee...

> How is this situation different from the user code, say, accessing the Internet? A blocking operation, which blocks on IO, _just blocks_. - we have no control over it...

> If the 3rd-party implementation is some arbitrary code, then either you can require that it does nothing blocking there Ok, but let's consider this: - There is a blocking...

>> But with this approach there will be no guarantee that the parallelism is equal to CPU count > > That's another big thing I don't understand, yes. Do you...

> It's basically a black box that may or may not behave nicely with your threads. One of the reasons may be the use of runBlocking. With regular IO, where...