https://kotlinlang.org logo
Title
b

benkuly

02/03/2023, 7:36 AM
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).
s

Sam

02/03/2023, 7:41 AM
It will mean boxing every byte as an individual object, which is pretty heavyweight compared to using a ByteArray or ByteBuffer
j

jw

02/03/2023, 11:35 AM
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
y

yschimke

02/03/2023, 1:01 PM
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.
b

benkuly

02/16/2023, 7:23 AM
Thank you for your thoughts. So a
Flow<ByteArray>
with a fixed
ByteArray
size would be better?
y

yschimke

02/16/2023, 7:43 AM
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.
b

benkuly

02/16/2023, 9:36 AM
How would that look like?
y

yschimke

02/16/2023, 9:39 AM
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.