You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm a little confused about what the current recommendation for doing blocking IO is, both in Kotlin Coroutines as a whole, and in ktor. I've read Kotlin/kotlinx.coroutines#261 and a bunch of issues that link to it. I assume it's withContext(Dispatchers.IO), but that doesn't actually seem to be in any documentation for either Kotlin Coroutines or Ktor!
One specific confusion I have — my understanding is that the cool thing about Dispatchers.IO (vs just Executors.newFixedThreadPool().asCoroutineDispatcher()) is that individual threads aren't permanently assigned to Dispatchers.Default vs Dispatchers.IO, and withContext(Dispatchers.IO) can often just mean adjusting the thread assignment counts without a full context switch. (I've also discovered that with the internal API (Dispatchers.Default as ExperimentalCoroutineDispatcher).blocking(N) I can create my own Dispatchers.IO-like dispatchers so that I can limit particular types of IO (sql, etc) to a specific number of threads in that thread pool.)
However, I also note that in the Netty engine (which we are using kind of by default, porting our app from Netty-based Ratpack), the dispatcher used for ApplicationCalls isn't Dispatchers.Default at all, but a Netty-specific dispatcher that just sends the coroutine directly to Netty.
I assume I still need to use some alternative dispatcher for blocking code, right? Netty's event loop also wants to not block?
But in this case is there any real point with Ktor/Netty to using Dispatchers.IO instead of Executors.newFixedThreadPool().asCoroutineDispatcher()? If the advantage of Dispatchers.IO over Executors.newFixedThreadPool().asCoroutineDispatcher() is that it can reuse a thread from Dispatchers.Default but we're not using Dispatchers.Default, should I even bother? I suppose I do still get to share threads between multiple dispatchers made with .blocking().
The text was updated successfully, but these errors were encountered:
Although, heh, looks like CIO uses the same code as Dispatchers.Default/IO but its own version? And doesn't expose them in an easy way to make your own separate blocking subpool either?
I'm a little confused about what the current recommendation for doing blocking IO is, both in Kotlin Coroutines as a whole, and in ktor. I've read Kotlin/kotlinx.coroutines#261 and a bunch of issues that link to it. I assume it's
withContext(Dispatchers.IO)
, but that doesn't actually seem to be in any documentation for either Kotlin Coroutines or Ktor!One specific confusion I have — my understanding is that the cool thing about
Dispatchers.IO
(vs justExecutors.newFixedThreadPool().asCoroutineDispatcher()
) is that individual threads aren't permanently assigned toDispatchers.Default
vsDispatchers.IO
, andwithContext(Dispatchers.IO)
can often just mean adjusting the thread assignment counts without a full context switch. (I've also discovered that with the internal API(Dispatchers.Default as ExperimentalCoroutineDispatcher).blocking(N)
I can create my ownDispatchers.IO
-like dispatchers so that I can limit particular types of IO (sql, etc) to a specific number of threads in that thread pool.)However, I also note that in the Netty engine (which we are using kind of by default, porting our app from Netty-based Ratpack), the dispatcher used for ApplicationCalls isn't
Dispatchers.Default
at all, but a Netty-specific dispatcher that just sends the coroutine directly to Netty.I assume I still need to use some alternative dispatcher for blocking code, right? Netty's event loop also wants to not block?
But in this case is there any real point with Ktor/Netty to using
Dispatchers.IO
instead ofExecutors.newFixedThreadPool().asCoroutineDispatcher()
? If the advantage ofDispatchers.IO
overExecutors.newFixedThreadPool().asCoroutineDispatcher()
is that it can reuse a thread fromDispatchers.Default
but we're not usingDispatchers.Default
, should I even bother? I suppose I do still get to share threads between multiple dispatchers made with.blocking()
.The text was updated successfully, but these errors were encountered: