BufRead doesn't seem to provide enough information

[delicate zealot]

I am using a BufRead to abstract over file, network or test-string. Is there any way to distinguish between "haven't gotten any new data yet but keep waiting" and "will never get new data"? I was just calling fill_buf() repeatedly until a frame arrived, then processing and consuming it, but it seems that a string containing half a frame will just cause an infinite loop because I can't distinguish it from a live connection that might still get more data and thus form a complete parsable frame.

[limber bane]

fill_buf giving an empty slice indicates EOF

[delicate zealot]

@limber bane (1) does that mean it blocks if, say a port is not open but also hasn't received data? (2) if the data wasn't consumed, is there no way to tell? if I get partial data I dont entirely consume, do I have to move it to a separate buffer to identify the meaning of the next slice?

or is the invariant "IF AND ONLY IF fill_buf lenght == previous fill_buff length THEN stream closed"?

that would be ideal, but is not implied as far as I can tell from what I read in the docs

[delicate zealot]

ok, I worked out that BufRead is just the wrong API, and I am going to try embracing the Tokio and AsyncRead

[limber bane]

(1) Yes
(2) Yes and Yes

[limber bane]

You have to consume the full thing each time before you can expect more data

Otherwise implementing the trait would be impractical for fixed-size buffers

which basically all BufReads are

[limber bane]

Note that othet than beïng async, AsyncRead’s API is strictly underpowered in comparison to BufRead

[delicate zealot]

I think the idea is that codec provides a lot of the logic for parsing "frames" of data.