Hey, I was reading some androiddev stuff on reddit and i've stumbled upon Vasiliy's rant on coroutines: https://www.techyourchance.com/kotlin-coroutines-in-complex-scenarios/. Apart from doing weird points he mention blocking issue - i've investigated his code but I need some help with understanding the reason. For me it looks like deadlock - dispatcher tries to dispatch coroutine on already locked (BlockingQueue) thread and we're ending up with Producers or Consumers only without chance to dispatch other type of worker. Am I right?

He makes some good points, I hope the coroutines devs are listening,

Maybe a bit about documentation. Others complaints are far-fetched in my opinion.

fyi, blocking is an anti-pattern with coroutines. not sure of the exact argument, but it is weird to see BlockingQueue

I know, I think it was created with thread-mindset. There are few other things wrong with this and original code. But it would be great to understand what causes the issue, how dispatchers behave when blocking code is executed.

they behave the same as when non-blocking but also non-cancellable code is executed

I meant this exact example I've posted above 😉

so for one thing, that example is going to see artifically decreased throughput due to the log lines, since

println

is just a call to

System.out.println

in JVM, and that is synchronized. blocking queue probably suffers similar issues (you're trying to block on a single queue 64+ times!). overall, the whole thing can really only support about 1/2 threads of throughput, because there is synchronized blocks. coroutines don't really factor into the equation here

It's not about throughput, it's about deadlock. IO provide 64 threads by default. Vasiliy tried to override it with Integer.MAX_VALUE with same result, before OutOfMemory. I'm trying to undestand why it was blocked.

probably because there's only a throughput of 5 on the queue, but it starts up to 64 providers

that is a bit facepalm moment for me 😄

as to why Integer.MAX_VALUE -> OOM, the IO threads might be pre-emptively started, so you're trying to allocation way too many threads at once

especially android phone, but for IO it's not the case, I think it starts more threads if needed with few started by default

I don't think so, since the tasks are retrieved by the thread like a normal thread pool