https://kotlinlang.org
Join Slack
Hey, I was reading some androiddev stuff on reddit and i've stumbled upon Vasiliy's rant on corouti...
# coroutines
b
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?
f
He makes some good points, I hope the coroutines devs are listening,
b
Maybe a bit about documentation. Others complaints are far-fetched in my opinion.
o
fyi, blocking is an anti-pattern with coroutines. not sure of the exact argument, but it is weird to see BlockingQueue
b
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.
o
they behave the same as when non-blocking but also non-cancellable code is executed
"non-blocking", to be precise
b
I meant this exact example I've posted above 😉
o
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
b
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.
o
probably because there's only a throughput of 5 on the queue, but it starts up to 64 providers
all the providers are waiting to push items to the queue, but all IO threads are blocked so no consumers can run
b
that is a bit facepalm moment for me 😄
o
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
or maybe ~10k threads is just too much for the system ^_^
that'd be about 10gb of memory
b
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 was focused on coroutines launching and I didn't see obvious answer, thanks
One more thing: is it possible that dispatcher queues coroutine for already blocked thread?
o
I don't think so, since the tasks are retrieved by the thread like a normal thread pool
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by