I'm curious: Speaks anything against using a

Flow<Byte>

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

Flow<ByteArray>

with a fixed

ByteArray

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.