Regarding the selection of dispatchers for ktor cl...

# ktor

[rocketraman]

Regarding the selection of dispatchers for ktor client calls... I see many people surround ktor client calls with <http://Dispatchers.IO|Dispatchers.IO> -- here is

an example from a recent popular YouTube video▾

. This seems wrong -- IO is of course designed for blocking I/O, but the ktor call may or may not be blocking depending on the underlying engine. Ktor presumably internally uses the appropriate dispatcher based on whether the actual engine in use is blocking or not. Calling code is therefore free to use a dispatcher based on its own requirements e.g. limiting the number of concurrent requests or whatever, rather than coupling the choice of dispatcher to the engine configuration.

If this is right, some official guidance around this would be welcome here and in the docs.

[Aleksei Tirman [JB]]

Can you please file an issue to address this problem?

[rocketraman]

https://youtrack.jetbrains.com/issue/KTOR-8168/Documentation-Provide-guidance-on-dispatcher-selection-for-client-code

[Aleksei Tirman [JB]]

Thanks.

[Todd]

Good call. My understanding was that ktor uses Dispatchers.IO by default so you shouldn't have to switch yourself. But would be nice to see it explicitly called out.

https://github.com/ktorio/ktor/blob/26ed3b11dc2ac91db98dadbab1faf9ac93fde1dd/ktor-[…]t-core/common/src/io/ktor/client/engine/HttpClientEngineBase.kt

[rocketraman]

Seems like the Darwin and curl engines use `Dispatcher.Unconfined`: https://github.com/search?q=repo%3Aktorio%2Fktor%20%20%20%20%20%22override%20val%20dispatcher%20%3D%20%22&type=code, but both of these just queue up the operation and do the actual I/O elsewhere i.e. curl uses a dedicated thread dispatcher, and Darwin uses an NSOperationQueue. So even here, wrapping the ktor call in <http://Dispatchers.IO|Dispatchers.IO> does not make sense.

[rocketraman]

It looks like the non-blocking CIO engine does not override the IO dispatcher from HttpClientEngineBase, which seems odd to me. Why would it use the IO dispatcher?

[bk9735732777]

@rocketraman I did not get the point where you said the calls may or may not be blocking? so you mean some clients calls may also not be blocking ? I didn't get it

[rocketraman]

@bk9735732777 Some client calls may not be blocking, and some may already be wrapped in an IO dispatcher by Ktor itself. Have you read the linked issue I created? Is there still any confusion?

[bk9735732777]

@rocketraman no i have read that but the only small doubt i have is i understand some may already be wrapped in an IO dispatcher by Ktor itself or some other dispatcher also but this part,
but Some client calls may not be blocking this part i don't get like won't network calls are always blocking if done on main thread. that is the reason we use coroutines right?

[rocketraman]

@bk9735732777

> won't network calls are always blocking if done on main thread
Not really. Network calls are non-blocking when a platform-specific non-blocking I/O facility is used. On Linux (including Android), this is epoll, on BSD (including Mac) this is kqueue, and on Windows this is IOCP. java.nio is an abstraction over these platform-specific capabilities on the JVM/Android. Coroutines don't add any new capabilities here.

> that is the reason we use coroutines right?
What coroutines bring to the table is allowing these non-blocking calls to suspend so that we can write our program as if the call was blocking and synchronous, which makes our code much easier to understand.