A modern programming language that makes developers happier.

kotlinlang

What is the intended/recommended way of setting context for `runBlocking`?

Directly via runBlocking parameter
```runBlocking(<http://Dispatchers.IO|Dispatchers.IO>) {
...
}```
or via `withContext`?
```runBlocking {
  withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
...
  }
}```
Quick debugging confirms my interpretation of the documentation that in the second case the internal `eventLoop` is not defined although I have no clue exactly what consequences this has. Can anyone shed more light on this?

`runBlocking` has a `context` parameter, so `runBlocking(<http://Dispatchers.IO|Dispatchers.IO>) { }`

Yes, I know (see my first example). I'm asking whether there's any difference to my second example (where I verified that the internal `eventLoop`  variable is null).

I'm basically asking if I need that default `eventLoop`  dispatcher or I can safely replace it with my own dispatcher (which possibly doesn't implement `eventLoop` ).

I'd just provide the context directly, as in your first example. Otherwise you're creating the event loop and then not using it for anything. Although there are behaviour differences between using the event loop and not using it, there's no meaningful difference between the two different ways of not using it.

Oh, so the event loop is actually. useless in my case. So can it be said that providing (any?) explicit dispatcher fully replaces the need to use the event loop?

Yes :+1:. If there's no event loop, the current thread will just block and wait for the job to finish.

But technically the event loop also blocks the underlying thread and the calling code waits for runBlocking to finish, right? So what's the difference?

The thread is being blocked by `LockSupport.park` and it's being undone by `LockSupport.unpark` so the eventloop is not responsible for that. The eventloop is meant such that you can return to the caller thread within the coroutine system for context preservation).

Take following example:
```suspend fun main() {
   println(Thread.currentThread().name) // main
   withContext(Dispatchers.Default) {
     println(Thread.currentThread().name) // default-worker
   }
   println(Thread.currentThread().name) // default-worker
}

fun main(): Unit = runBlocking {
   println(Thread.currentThread().name) // main
   withContext(Dispatchers.Default) {
     println(Thread.currentThread().name) // default-worker
   }
   println(Thread.currentThread().name) // main
}```
Thanks to the eventloop the last thread printed in the `runBlocking` example is `main`

The important bits of source code are (surprisingly) mostly in one file, so you can readily see what's going on. <https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/src/Builders.kt#L82-L89|Here's the loop>.
• If `eventLoop` is `null`, the thread is just parked indefinitely, until the job completion triggers it to unpark.
• If `eventLoop` is non-null, the thread is parked only when it runs out of events. If the event loop has events scheduled for the future, the thread is parked until those events are ready. Otherwise, it's parked indefinitely. It can be unparked either by completion of the job or by a new event being dispatched to the event loop.

Thanks! The example helped. The takeaway is (I hope) that unless I care about which thread continues the execution after a coroutine block then the distinction is quite insignificant.