I'm curious: Speaks anything against using a `Flow...

# coroutines

[benkuly]

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).

[Sam]

It will mean boxing every byte as an individual object, which is pretty heavyweight compared to using a ByteArray or ByteBuffer

[jw]

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

[yschimke]

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.

[benkuly]

Thank you for your thoughts. So a Flow<ByteArray> with a fixed ByteArray size would be better?

[yschimke]

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.

[benkuly]

How would that look like?

[yschimke]

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.