feat(bytesbuf_io): add ConcurrentRead and ConcurrentWrite traits

[sandersaares]

Summary

Add ConcurrentRead and ConcurrentWrite traits to bytesbuf_io to support concurrent I/O operations.

Motivation

The existing Read and Write traits take &mut self, limiting callers to one operation at a time. Some I/O endpoints (e.g. those backed by completion-based I/O models) can support many operations in flight simultaneously for higher throughput.

Changes

• ConcurrentRead trait - takes &self and returns an independent Read handle via concurrently(), enabling multiple concurrent reads
• ConcurrentWrite trait - takes &self and returns an independent Write handle via concurrently(), enabling multiple concurrent writes
• Both traits share the same supertraits as Read/Write (HasMemory + Memory + Debug)
• Added Implementors to the spelling dictionary

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (162d353) to head (851fc5b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #292   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         144      144           
  Lines        8917     8917           
=======================================
  Hits         8917     8917           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Vaiz]

if the problem is that Read uses mut reference, all we need is an extension for Read trait that allows to get another copy of this instance

it could look like this

pub trait ConcurentRead : Read {
    fn duplicate(&self) -> Self;
}

the benefit is that you don't need Handle type and the trait itself acts like an extension for Read types

[sandersaares]

This alternative formulation feels more limiting. Why should we restrict implementations to only returning Self? The current form feels more flexible at no real cost. Or am I missing some hidden cost/complexity?

[Vaiz]

Handle type adds some level of complexity, probably it will look worse in method's signatures

fn open_concurrent_read<P, R>() -> P 
where 
  P: ConcurrentRead<Handle: R>
  R: Read + Send + 'static,
{
//...
}

alternative

fn open_concurrent_read<R>() -> R
where 
  R: ConcurrentRead
{
//...
}

and also the name is ConcurrentRead, but it doesn't really have any read methods, so it's more like ConcurrentReadProvider or something

[martintmk]

Wouldn't just making the Read implemnet Clone essentially making it concurrent?

This way, you don't even need to introduce new trait anymore.

[sandersaares]

Wouldn't just making the Read implemnet Clone essentially making it concurrent?

This also has the limitation that it forces each read to go through a Self. This seems like an unnecessary limitation.

[sandersaares]

and also the name is ConcurrentRead, but it doesn't really have any read methods, so it's more like ConcurrentReadProvider or something

Agreed but that "provider" style felt too verbose. Do you have shorter alternative name suggestions? Concurrent is a long word :)

[martintmk]

This also has the limitation that it forces each read to go through a Self. This seems like an unnecessary limitation.

Why is this a problem?

edit: If i read the API properly, you use concurrent method to retrieve the handle. You could do the same thing by cloning the type that implements Read trait and continue using it on other scope.

To me, the flow is almost identical.

[sandersaares]

You could do the same thing by cloning the type that implements Read trait and continue using it on other scope.

There is no guarantee that the type that implements Read can be cloned. The concept of "clone" is bigger than "concurrent reads" - we should not impose big-picture requirements like "must support cloning" just to enable concurrent reads.

I agree the flow is the same - but this is not a question of what the code to use the type looks like, this is a question of what requirements we impose to support concurrent access. Being able to clone Self feels like a suspiciously large requirement because it affects more than just the "reading" API surface.

That is not to say that I am completely against it but for a general-purpose API it does not feel like a conservative choice that favors stable long-term APIs.

[Vaiz]

what about ReadDemux/ReadDemultiplexer name?

[sandersaares]

Demux/Demultiplexer implies something completely different in my view (e.g. that the input is multiplexed, which it is not), does not feel appropriate as a name for this abstraction.

[geeknoid]

Why is Debug a requirement here? That seems like an anti-pattern to me.

[sandersaares]

Generic code without Debug requirements gets annoying because you cannot debug-print stuff even though 99% of things implement Debug. I feel we can expect all but the most private types to always implement Debug just to make the dev UX easier.

[geeknoid]

The naming feels strange to be. "Read" is a trait that has read methods on it, whereas this ConcurrentRead doesn't. I was expecting to see "concurrent read methods" (whatever that would be).

This feels more like a clone-like thing. Like ReadClone and WriteClone?

[sandersaares]

Cloning is intentionally not part of the picture - the thing being returned is not a clone, it is a new object that can be used to issue reads concurrently. Open to better names. In the same family of traits we might have "Deferral" capabilities. ReadDefer and ReadConcurrent maybe?

[sandersaares]

Going on vacation, so marking as draft - will continue processing the topic when back.