# Deep dive: Design of async IO traits

Link to document: https://github.com/nrc/portable-interoperable/blob/master/io-traits/README.md

###### tags: `deep-dive`

Leave questions, observations, discussion topics below.

---

## Requirements

eholk: "Traits should work well as trait objects" - After we have AFIDT, `dyn*`, etc., more things may be dyn-safe than they are now. If we rely on these features for async I/O trait objects, does that still satisfy this goal?

nrc: People use trait objects a lot for I/O. They have to work well with dyn*. But if stuff can work without that, maybe that's better?

eholk: So if it works well with trait objects but requires dyn* that satisfies the requirement.

tmandry: "buffers should not be constrained to a single concrete type." – Is this in support of the goal below (allocated on the stack or owned by other data structures), or is there more to it? It seems like you could refine this requirement to another reason behind it.

nrc: Today it's a mutable slice which is somewhat abstract (e.g. you can use a Vec or whatever). Antipattern is tokio's Bytes type, people hated that and wanted to use their own. Also don't want to assume that `Vec<u8>` is good enough.

tmandry: Why do people want to use their own? Management of the lifetime. Others?

nrc: Control over allocation. For example, you have a data structure that works with memory mapped files, or funky data structures like a rope (you could take a slice of components of it).

---

## Readiness read

eholk: Would it make sense to add a builder API for `Interest` and `Readiness`? Right now it looks like we'd have a bunch of constants that can be ored together, but a higher level API would be nice.

nrc: That was in a previous version, just haven't copied it over.

---

## Adapter types and downcasting

tmandry: For adapter types, how "branchy" will they have to be to make use of `ReadyRead`/`OwnedRead` impls of the inner type? Is there an opportunity for the other versions to be optimized out? (If not should we just be using `dyn` for those?)

tmandry: Can I implement the whole adapter type in the async fn, and does inline work there?

nrc: To be a good citizen you should implement all three traits, and in the basic `Read` trait you'd write out the downcasting branches and use the better implementation. But maybe that's not worth it. Not sure how well it would get optimized out.

tmandry: If we mark `as_ready` and `as_owned` as `inline(always)` we can optimize across compilation units.

nrc: Only in the static case; not for dyn. Then you need some good LTO/devirtualization

eholk: As long as you don't have a trait that's sometimes readiness or sometimes owned it should optimize fairly easily in the static case.

---

## Alternatives

tmandry: Would like to discuss these more. In particular, there was one proposal that let you share an implementation between the three approaches (I think). Here you have multiple implementations.

nrc: You're never going to get into an unexpected path; user has to opt-in to a specialized I/O model. Not going to opt in to both, only going to do 2 out of 3. Only adapters have to implement all 3.

tmandry: Why 2 and not 1?

nrc: One path which is optimal for your constraints if it's supported in the environment, and one that's slightly less optimal that's supported in all environments.

tmandry: Ok so end user is writing an app that might run in different environments.

nrc: Implementers also going to implement a couple. Tokio is going to focus on Readiness, Glommio might focus on Completion, for instance.

nrc: Tokio's interesting since it's adding uring. Depending on the platform, Tokio may not offer the uring implementation. Trait impls would depend on OS.

nrc: You also get the choice of saying you *only* support the completion system path.

tmandry: Lots of adapter types right?

nrc: Seems fairly common for e.g TLS.

tmandry: So you might be writing three paths. Maybe that's better than writing one path that behaves differently depending on the environment.

nrc: Goes back to question of whether to do the testing. Can only do testing at end user level.

tmandry: Testing at end user level makes sense. Still have three paths.

nrc: Adapter code would need to have paths for each approach and test those.

eholk: The adapters just have to implement the three traits. Where it gets tricky with the downcasting..

nrc: Question is whether the adapter should do its own downcast testing in the `Read` implementation. It's reasonable to say no; we can have the end user do it if they care. I think this is right. An adapter should implement all three traits but not downcast.

tmandry: End user of the Read trait might not be the application developer, could be a library like hyper.

nrc: I think that's okay; they know which scenarios they want to be usable in. Hyper is doing network I/O so readiness is probably the right tradeoff.

tmandry: I've seen completion IO in network environments but very specialized, not web servers, so I buy that.

---

nrc: One buried question is about allocators. The `OwnedRead` trait only works with the default allocator. Imagine `<A>` on the `OwnedRead::read` method. The allocator gets used in the dynamic destructor.

eholk: Not sure dyn* helps here.

eholk: Could make the allocator a `dyn*` or trait object?

eholk: Implement `From` for `Vec<_, dyn* Allocator>`

nrc: How to convert from a normal Vec?

nrc/ehok: `into_raw_parts` and then pass that into the new `Vec` type. Wildly unsafe

tmandry: We could encapsulate as `Vec::with_dyn_allocator(Self)`.

nrc: Has to allocate, might annoy some people.

eholk: Many allocators are ZSTs. Should eventually be able to coerce ZSTs to dyn*.

nrc: That would be cool.

---

tmandry: Coming back to the "three paths" problem, I'm still a little concerned about most code being in adapters where you have three implementations.

nrc: Problem with InternalRead is it requires you to decide which path to use in the implementation for that type. e.g. Socket doesn't know what the user's buffers look like.

tmandry: Curious if there's much commonality between the implementations. More of an open research question.

nrc: I think there's not a lot. For Readiness you have to do a two phase approach for there to be any point. OwnedRead and regular Read has some similarities, but not in a way that's easy to express in Rust.

nrc: Suspect that the different implementations will be frustratingly similar, but not enough to write with a macro.

tmandry: If we discover a macro approach it can exist in the ecosystem.

---