Re: Capy review

Ruben Perez wrote:
> On Tue, 30 Jun 2026 at 01:46, Peter Dimov via Boost <[email protected]
> <mailto:[email protected]> > 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.


_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/GV2WNRDMBF726EJ5HK3WMVW7NO2Y47WX/