Book: Chapter 20.1: incorrect statement about TcpStream buffering
The book states:
Finally, flush will wait and prevent the program from continuing until all the bytes are written to the connection; TcpStream contains an internal buffer to minimize calls to the underlying operating system.
But as far as I can see, there is no user-space buffering in TcpStream - it is just a wrapper of an underlying OS handle. Consequently, flush() is a no-op: https://github.com/rust-lang/rust/blob/93b6d9e086c6910118a57e4332c9448ab550931f/src/libstd/net/tcp.rs#L589
ztlpn
All 2 comments
Right鈥攁nd from what I understand the "stream.write" might potentially return before having written all bytes, as documented "Calls to write are not guaranteed to block waiting for data to be written".
Another thing that made me wonder, is the stream.read() which does one read from the socket, this may or may not be an entire HTTP request. I understand that the example is just an example, and maybe handling only good-weather outcomes is good enough, but I've seen people in various channels confused by this when moving on to writing real networking software.
vmedea
on 5 Sep 2019
Does anyone participating in this issue have a proposed fix?
carols10cents
on 30 Jan 2020
Related issues
xStrom
路
3Comments
xStrom
路
4Comments
nathany
路
3Comments
devimc
路
4Comments
serialhex
路
4Comments
Most helpful comment
Right鈥攁nd from what I understand the "stream.write" might potentially return before having written all bytes, as documented "Calls to write are not guaranteed to block waiting for data to be written".
Another thing that made me wonder, is the
stream.read()which does one read from the socket, this may or may not be an entire HTTP request. I understand that the example is just an example, and maybe handling only good-weather outcomes is good enough, but I've seen people in various channels confused by this when moving on to writing real networking software.