You probably want to limit number of concurrent connections, number of coroutines

I’d use a semaphore

You can have much more concurrently opened connections that are waiting for response, than you have threads, because coroutines are suspended while waiting for network

semaphore is the easiest to me, I’ve seen a suspending semaphore implementation in io.ktor.util.cio.Semaphore

dunno what can be more simple than a semphore

I thought it would always work but downside would be those threads cant be used for anything else but downloads

hence my attempt to impose this logically on top of IO

-- so youre saying, this should not be a dispatcher thing, bu a manual semaphore which would suspend a courinte while semaphore is turned on?

You can also limit concurrency with channels.

Producer / Consumer with channels is also an option, just not as simple as a semaphore

Create N consumers (downloading coroutines) and feed them via a channel. your producer will suspend if more than N downloads are in progress

Stop thinking threads, this is not your concurrent unit of work anymore 🙂

or maybe custom Dispatcher, wrapping IO and applying semaphores there?

number of concurrent operations

You cannot limit it with dispatcher, just because it's not how Coroutines work. I think to answer properly on your question you should give more details of what exactly you want to limit and what is your use case

I mean unsuspended

So, what is your use case and what you want to achive?

now I run it on IO = unlimited parallel downloads, which is not good in my case and want to limit it to say 5

so overflowing requests need to be queued and processed when dispatcher is free

No I'd only want to limit file downloads / uploads explicitly, shouldn't leak to other requests, glide, etc

If you use Glide you probably use okhttp, right?

isnt it basically the same? separate dispatcher vs clone of okhttp threads

Own coroutines dispatcher wouldn't help you on this case if you use asyncronous API of okhttp

Solution with okhttp dispatcher instead of coroutines is more powerful and optimal, it knows about amount of connections and hosts

And also allows you limit parallelism without using blocking API of okhttp and in case of coroutines dispatcher you have to use it everywhere to limit parallel requests, but In case of limit on level of http client you can share this client between different parts of your code and even with third party libraries

why wouldnt it even work you think? afaik there wouldn't be a thread free to call that retrofit/okhttp call

ooh you mean my thread would become free once hopped of to okhttp thread, hence allowing to call new okhttp calls?

Only if you use blocking Retrofit API, but don't think you do

It also can be implementation details of your downloader if you wish, the same way as you want to create own coroutines dispatcher

And I disagree that it's uglier, it's just dependency injection, when downloader knows nothing about parallelism, but http client with required config is injected

If you want to make this limit per instance of your downloader, not by Retrofit service, just use kotlinx.coroutines Semaphore, as was suggested above. We don’t have details of your architecture and what exactly you want to limit. how and why

was very helpful