A modern programming language that makes developers happier.

kotlinlang

What happens if I use withContext(<http://Dispatchers.IO|Dispatchers.IO>) and execute a lot of calls, is there a limit? what if all the threads are busy spinning? How to provide backpressure? Don't want to reach out of memory. <@U0BRK9HC5>

IO dispatcher uses thread pool
<https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html>

Size of this thread pool can be configured

&gt; what if all the threads are busy spinning
Than coroutine will not be dispatched and will wait in the event queue nothing will be executed

&gt; How to provide backpressure
There is no such mechanins on dispatcher level, task still will be added to event queue
Tho, instead of run too many withConttext(IO) you can write own abstraction on top of it that limit amount of requests, for example use Semaphore or worker pool pattern

but if the thread is not spinning, and suspended, then it's considered "free to be used", so 64 must be ok

because all the threads will do is send an http request and parse some xml

&gt; do is send an http request
Which can be improved by using asynchronous http client

or even blocking http client with asyncronous API which has own connection limit

Untitled

&gt; parse some xml
Which sounds more like CPU-bound task, so you should probably use differentt dispatcher for this

yes, or even create own dispatcher only for this task. depends on your case

&gt; `<http://httpClient.post|httpClient.post>`
is this Ktor Http Client?

Ktor Http client already asyncronous (implementation depends on the used engine), so it anyway will not use and will not block your IO dispatcher

even in this case, everythting is asyncrnous

ktor client is asyncrnous, even if actual IO is blocking it’s already handled by own thread pool of the engine

but the XML parsing is still expensive but maybe it's only that parth worth running on another thread

because yes the http request is already suspending and giving back the thread

also it would be much more clear from API point of view

the xml i get can be huge that's why, I am afraid to stop for too long the caller thread

Yes, this is why you should extract it to suspend function that use `withContext(SomeCPUBoundDispaccther)`, so it will be safe to use this function from any other suspend function