https://kotlinlang.org logo
#coroutines
Title
# coroutines
b

bholota

11/09/2019, 10:45 PM
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

Fudge

11/09/2019, 11:12 PM
He makes some good points, I hope the coroutines devs are listening,
b

bholota

11/09/2019, 11:23 PM
Maybe a bit about documentation. Others complaints are far-fetched in my opinion.
o

octylFractal

11/10/2019, 12:19 AM
fyi, blocking is an anti-pattern with coroutines. not sure of the exact argument, but it is weird to see BlockingQueue
b

bholota

11/10/2019, 12:23 AM
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

octylFractal

11/10/2019, 12:26 AM
they behave the same as when non-blocking but also non-cancellable code is executed
"non-blocking", to be precise
b

bholota

11/10/2019, 12:48 AM
I meant this exact example I've posted above 😉
o

octylFractal

11/10/2019, 12:56 AM
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

bholota

11/10/2019, 1:06 AM
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

octylFractal

11/10/2019, 1:07 AM
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

bholota

11/10/2019, 1:09 AM
that is a bit facepalm moment for me 😄
o

octylFractal

11/10/2019, 1:10 AM
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

bholota

11/10/2019, 1:11 AM
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

octylFractal

11/10/2019, 2:13 AM
I don't think so, since the tasks are retrieved by the thread like a normal thread pool
3 Views