Closed jessa0 closed 1 year ago
Thanks for the PR. I think more correct fix here is avoiding calling fill_buf twice. https://github.com/tokio-rs/tokio/commit/1409041525cc81d81b3405c59e5d001b1ec1ddcb
That would be better indeed. If you're willing to merge that tokio commit, want me to bring it into this PR for you?
I hit this
unreachable!()
insideFillBuf
with anAsyncRead
implementation (wrapped in aBufReader
) which calls a Javascript callback thruneon
(which is an async operation) for the actual read, which means every "new"poll_read
(i.e. either the first call ever or the first call after aReady
is returned) will returnPending
at least once, including after EOF is hit, which is what triggers this bug. Of course, theAsyncRead
implementation could track when EOF is hit and returnReady(0)
forever after that, which is indeed what I used as a workaround, but I can't find anything in theAsyncRead
documentation which actually requires implementors to do this.Alternatively to this fix, the
AsyncRead
documentation could require implementors to always returnReady(0)
after an EOF, and theunreachable!()
changed to apanic!()
, but that seems like more potential downstream work than merging this fix, and seems easy to screw up.Another similar alternative would be for the
AsyncBufRead
documentation to require implementors to always returnReady(&[])
after an EOF.The added test triggers the panic if run without the bug fix.