Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async local io #1115

Merged
merged 2 commits into from
Jun 21, 2023
Merged

async local io #1115

merged 2 commits into from
Jun 21, 2023

Conversation

rklaehn
Copy link
Contributor

@rklaehn rklaehn commented Jun 20, 2023

Async local io

this does not really make too much sense right now, but will become part of the workspace once the iroh crate split is done.

@rklaehn rklaehn changed the base branch from main to refactor-crates June 20, 2023 12:17
@rklaehn rklaehn force-pushed the iroh-io branch 2 times, most recently from 35d8913 to 3f52a5b Compare June 20, 2023 13:08
@rklaehn rklaehn marked this pull request as ready for review June 20, 2023 13:09
@rklaehn
Copy link
Contributor Author

rklaehn commented Jun 20, 2023

@Arqu any idea about these failures?

error: failed to run custom build command for openssl-sys v0.9.88

No idea why it is trying to build openssl-sys in the first place. openssl-sys is not a dependency. I guess these have to be installed on the runner?

Cargo.lock Outdated
"lazy_static",
"libc",
"log",
"openssl",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pulling it in

Cargo.lock Outdated
@@ -2799,10 +2956,12 @@ dependencies = [
"http-body",
"hyper",
"hyper-rustls",
"hyper-tls",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd check we don't accidentally pull in hyper-tls (think it's on be default and needs to be excluded or something like that)

@rklaehn rklaehn force-pushed the iroh-io branch 3 times, most recently from e0ee56f to 5edef76 Compare June 20, 2023 14:48
@rklaehn
Copy link
Contributor Author

rklaehn commented Jun 21, 2023

This is already published. Here are the docs: https://docs.rs/iroh-io/0.1.0/iroh_io/

proptest = "1"
tempfile = "3"
tokio = { version = "1", features = ["rt", "test-util", "macros"] }
warp = { version = "0.3.5", default-features = false }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be great to switch this to axum, given that is already in our dependency tree for the derper. (as a follow up)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, on my todo list, especially given that warp does http range requests wrong.

iroh-io/README.md Outdated Show resolved Hide resolved
Copy link
Contributor

@dignifiedquire dignifiedquire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall. I haven't reviewed the details of the impl, just general structure.

&mut self,
offset: u64,
data: [u8; N],
) -> Self::WriteArrayAtFuture<'_>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be nice to provide a default impl that just fallsback to use write_at

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😢 default impls would require defaults for associated types, which are unstable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😭

// let buf = resource.read_at(1000000, 100).await?;
// println!("buf: {:?}", buf);
// Ok(())
// }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's up with this test?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just a thing to explore the behaviour of one particular http server that supports range requests. Since it is on IPFS I don't want to keep it enabled. I guess I could just disable it instead of commenting it out.

use futures::future;
use std::io;

impl AsyncSliceReader for bytes::Bytes {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you plan on adding impls for Vec<u8> and std::io::Cursor potentially? might be quite nice

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, for Vec it would basically be the same. Cursor I am not sure about since you don't have the notion of a "current position".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would also be good to test that this interface works with https://docs.rs/mmap-rs (and potentially adding a cfged impl to this code) as this would likely be a nice speedup in a bunch of cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a thought though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh boy, that is a can of worms.

So - it is definitely possible to do an impl of this that uses memory mapping. There is a big but though: since there is no custom constructor for Bytes you would have to copy from the memory mapped region into the Bytes, even if you could ensure that the Bytes will keep the memory mapped buffer alive.

I have opened an issue on bytes::Bytes for this, and so have other people. But so far no success. For other projects I have therefore decided to write my own Bytes equivalent type. But for this crate I decided to go with Bytes since it is ubiquitous and the Bytes/BytesMut combo is quite helpful when doing zero alloc IO (splitting off Bytes from a BytesMut etc) and I did not feel like reimplementing all of this.

This was my issue:
tokio-rs/bytes#571

The other issues:
tokio-rs/bytes#437
tokio-rs/bytes#526

My version of Bytes:
https://github.com/cloudpeers/radixdb/blob/master/src/store/blob_store.rs#L37

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way: what is the current crate for memory mapped IO?

There is memmap, memmap2, and now this mmap-rs

I thought memmap2 was the current one... 🤷‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is memmap2 download stats. It certainly seems to be popular...

image

**h = Some(state);
r
}
Err(_) => Err(io::Error::new(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would probably be helpful to at least include the error in the message?

@rklaehn
Copy link
Contributor Author

rklaehn commented Jun 21, 2023

Looks good overall. I haven't reviewed the details of the impl, just general structure.

The impls are as simple as possible. There is an entire big can of worms called buffering that I will need to add. But not in this PR

also make sure the inner error is propagated when unwrapping a JoinHandle
@rklaehn rklaehn merged commit 23ea777 into refactor-crates Jun 21, 2023
@rklaehn rklaehn deleted the iroh-io branch June 21, 2023 10:17
matheus23 pushed a commit that referenced this pull request Nov 14, 2024
* feat: add iroh io

* docs: add badges and license information to iroh-io

also make sure the inner error is propagated when unwrapping a JoinHandle
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants