What happens if I use withContext(<Dispatchers.IO>) and execute a lot of calls, is there a limit? wh...

# coroutines

[coder82]

What happens if I use withContext(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. @gildor

[gildor]

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

[gildor]

Size of this thread pool can be configured

[gildor]

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

[coder82]

ok

[gildor]

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

[coder82]

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

[coder82]

for my use case

[gildor]

thread cannot be suspended

[coder82]

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

[gildor]

do is send an http request

Which can be improved by using asynchronous http client

[coder82]

aha that's a good point

[gildor]

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

[coder82]

This is what _I am doing now

Untitled

[gildor]

parse some xml

Which sounds more like CPU-bound task, so you should probably use differentt dispatcher for this

[coder82]

uhm true

[coder82]

rather Dispatchers.Default

[gildor]

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

[gildor]

<http://httpClient.post|httpClient.post>

is this Ktor Http Client?

[coder82]

yes

[coder82]

it's the default one

[gildor]

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

[gildor]

no need to use any dispattcher for tit

[coder82]

I am using the Apache engine

[gildor]

even in this case, everythting is asyncrnous

[gildor]

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

[coder82]

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

[coder82]

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

[gildor]

yes, probably, but only parsing

[coder82]

good point

[gildor]

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

[coder82]

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

[gildor]

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

[coder82]

👍