2 ms·
Taking in a generic T: Read is the recommended way to accept streaming inputs. It is up to the user whether they want to buffer or not. You can pass in a BufRea
by orlp 5y ago
Taking in a generic T: Read is the recommended way to accept streaming inputs. It is up to the user whether they want to buffer or not. You can pass in a BufReader into a T: Read no problem, and it will buffer any reads. That the reads internally are buffered is an implementation detail serde_json has no business knowing about.
The converse is potentially disastrous - if you read too much from a TCP stream you could hang your program waiting for more input that never comes.
- scottlamb 5y ago> Taking in a generic T: Read is the recommended way to accept streaming inputs. Recommended by whom? When you want to process stuff in bulk, it's better to use BufRead::fill_buf (reusing the BufRead's buffer) rather than copy into your own. For example, I wrote some code which basically skips some escape bytes. [1] It wraps a BufRead and is itself a BufRead. Its caller actually can process bytes straight from the buffer of the BufRead you supply, skipping two layers of copying. > The converse is potentially disastrous - if you read too much from a TCP stream you could hang your program waiting for more input that never comes. You can implement any idea badly, but that doesn't mean the idea itself is bad. There's a difference between taking advantage of buffering and expecting to operate only on full, fixed-sized buffers. [1] https://github.com/dholroyd/h264-reader/blob/60ed66dc4dbfe745ceff80692902273b260f2ba9/src/rbsp.rs#L46 https://github.com/dholroyd/h264-reader/blob/60ed66dc4dbfe74...