Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
byteorder crate does not play nicely with our "non-blocking" IO #2820
We jump through a lot of hoops with
But when we call the various low-level
It seems like it is entirely possible for a u64 or other multi-byte value here to cause our non-blocking IO to fail on a partial read.
So there's actually a couple of layers of indirection going on here.
I think what is happening is the following -
We then read from this vec of bytes to actually deserialize the appropriate msg header or msg body.
And since we only start deserializing once we have a full vec of bytes we can safely make the assumption that we will never read partial bytes. We are not reading off a stream, we are reading from the intermediate vec of bytes which is filled before we begin.
Rust IO really is kind of janky as we do not get any type safety here in terms of blocking/non-blocking behavior.
Q) In an ideal world would