I'm curious: Speaks anything against using a `Flow...
# coroutines
I'm curious: Speaks anything against using a
for IO? I use it in my library Trixnity and have no problems with it so far. I use it as common layer for ktor (here) and okio (here).
It will mean boxing every byte as an individual object, which is pretty heavyweight compared to using a ByteArray or ByteBuffer
It also means every layer gets suspend machinery which bloats and slows down the code. Code that reads four bytes into an int has to handle suspension
I haven't seen anything better than grabbing an IO thread and doing a sequence of IO operations to completion. It doesn't have a clean 1:1 mapping to Flow, but is probably close to optimal in most cases.
Thank you for your thoughts. So a
with a fixed
size would be better?
Yes. But in my code I even avoid the Flow, and just have synchronous imperative code that fully completes the IO operation in a borrowed IO thread.
How would that look like?
It may not work for your case. For me not having a separation between the producer and consumer via Flow. That flow separation possibly goes over different coroutine dispatchers (hopefully not via default/io thread sharing). Instead just having a thread that reads from the stream and processes the input.