but it doesnt seem to add too much value over just using
BlockingQueue
for this case, I guess
z
Zach Klippenstein (he/him) [MOD]
12/03/2019, 8:28 PM
If you want a blocking API, that doesn’t look particularly unidiomatic.
If you want a non-blocking API, which seems to be what you’re really asking about, then just use a
Channel(capacity = UNLIMITED)
to get an unbounded channel, and use
channel.offer
instead of
channel.send
to send to the channel without suspending.
e
ec
12/03/2019, 8:35 PM
Thx for the tip, from performance standpoint is Channels better for Kotlin compiler ? Also considering there will be sh!t tons of data putting(frequent), is it better to have a Channel for each sub. then fanning in to output Channel?
z
Zach Klippenstein (he/him) [MOD]
12/03/2019, 9:50 PM
from performance standpoint is Channels better for Kotlin compiler?
Better than what, using a
LinkedBlockingQueue
? I don’t think the compiler cares either way. Unlimited-capacity channels are effectively linked blocking queues that suspend instead of block, which lets you scale the number of suspending operations a lot more than blocking ones because they’re not pinned to threads.
As for one vs multi channel performance, I’m not sure. I’d build it the simplest way first, then benchmark + profile, and optimize from there.