Ruben Perez wrote:
On Tue, 30 Jun 2026 at 01:46, Peter Dimov via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org> > wrote:
Ruben Perez wrote:
My use case (length-prefixed message protocols) looks like a good use case for capy::read (plain buffer version). Actually, the reference section lists this use case as example [18]. I'm not sure this pattern is efficient, though, as with most streams in Corosio you'd be running two syscalls per message. As an improvement, I could implement a wrapper stream that buffers bytes (à la Asio's buffered_stream [19]), but manual handling looks simpler to me.
Buffered streams are absolutely essential for performance when serializing or deserializing (e.g. over binary protocols), see
https://github.com/pdimov/corosio_protocol_bench
They are if you mix deserialization and reading like in your benchmarks. My experience doing this has been negative for a number of reasons.
I wonder how much of that negative experience has been caused by not using a buffered stream to begin with. :-)
Since all the protocols I implement have the notion of messages (length prefixed), I read at least one message into a resizable buffer, then deserialize it. Most of the times, you actually read more than one message, so my primitive would be something like
read_some_messages(Stream&, Buffer&) -> range of message
Which is somehow handling the buffering myself, rather than using buffered_stream explicitly.
This is also why I'd find the read_at_least function that you proposed in Slack useful. Although I can live without it.
read_at_least is easy to implement now that we have buffer_slice, but then again, so is `read`. For me it doesn't make much sense to have one but not the other; they only differ by the stop condition being `== n` in one case and `>= n` in the other.