Skip to content
This repository has been archived by the owner on May 6, 2018. It is now read-only.

Add AllowSyncIo wrapper #76

Merged
merged 1 commit into from
Nov 7, 2017
Merged

Conversation

cramertj
Copy link
Contributor

This is nice to have when you're being lazy and combining synchronous file IO or stdin/out with the various tokio-io combinators. In general, I think it's good to discourage this kind of behavior, but I think the name in the API (AllowSyncIo) makes it pretty obvious and explicit what's going on.

@carllerche
Copy link
Member

Thanks. This type would be more generally useful bedsides just wrapping sync IO. For example, you could take an async IO handle, wrap it with some type that maintains the Async properties but doesn’t impl the Async traits. In this case, the type is still Async but just doesn’t impl the traits.

Given that, I wonder if there could be a more fitting name.

@cramertj
Copy link
Contributor Author

Yeah, I've got no problem changing the name-- I'm sure there's something better we could come up with.

@cramertj
Copy link
Contributor Author

@carllerche @alexcrichton Any ideas for a better name here?

@alexcrichton
Copy link
Contributor

Nah sorry, no ideas here :(

@Ralith
Copy link
Contributor

Ralith commented Oct 31, 2017

UnsafeAsync? AssertAsync?

@cramertj
Copy link
Contributor Author

cramertj commented Oct 31, 2017

@Ralith Yeah, originally I called it AssertAsyncIo, but that doesn't seem quite right because you can use synchronous IO here, it'll just cause the event loop to block.

@cramertj
Copy link
Contributor Author

Also @carllerche if you're trying to use it in that fashion, it should use try_nb! instead of ?, right? I think that would need to be a separate wrapper type.

@carllerche
Copy link
Member

@cramertj is there a reason not to always use try_nb!? In theory, std I/O handles shouldn't return it.

Some naming thoughts: AllowStd, WrapStd, AdaptStd. I generally like Std instead of Sync as that is basically what the wrapper is saying (allowing std::io::Read / Write).

@cramertj
Copy link
Contributor Author

cramertj commented Oct 31, 2017

@carllerche If we see EAGAIN on an IO interface that we expect to only implement Read/Write (i.e. not notify on availability), then we won't be able to properly handle that error and we should fail. However, I agree with you that EAGAIN probably just shouldn't appear in normal Read/Write types, so if you think it'd be better I'm fine with switching to try_nb! and renaming to AllowStd (perhaps AllowStdIo? I like keeping Io in there to explain what it's an adapter for).

@cramertj
Copy link
Contributor Author

cramertj commented Nov 1, 2017

@carllerche I've updated this PR to reflect the discussion.

@cramertj
Copy link
Contributor Author

cramertj commented Nov 1, 2017

Rebased.

@cramertj
Copy link
Contributor Author

cramertj commented Nov 7, 2017

@carllerche Are there any more changes you're looking for here?

Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

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

I added some inline comments. With those changes, I'm ready to accept the PR.

I don't love the Allow prefix (AllowStdIo), but I don't have any better ideas, so I'm OK w/ it.

src/allow_std.rs Outdated
fn shutdown(&mut self) -> Poll<(), io::Error> {
Ok(Async::Ready(()))
}
fn write_buf<B: Buf>(&mut self, buf: &mut B) -> Poll<usize, io::Error> {
Copy link
Member

Choose a reason for hiding this comment

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

This looks like the same impl as the default impl. Is there a reason why you included it?

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 was different when I used try! instead of try_nb!, but that's no longer the case, so I can remove it now.

src/allow_std.rs Outdated
impl<T> AsyncRead for AllowStdIo<T> where T: io::Read {
// TODO: override prepare_unitialized_buffer once `Read::initializer` is stable.
// See rust-lang/rust #42788
fn read_buf<B: BufMut>(&mut self, buf: &mut B) -> Poll<usize, io::Error> {
Copy link
Member

Choose a reason for hiding this comment

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

This looks like the same impl as the default trait impl. Is there a reason you included it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As above.

src/allow_std.rs Outdated
/// `AllowStdIo` will cause the event loop to block, so they should be used
/// with care.
#[derive(Debug, Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)]
pub struct AllowStdIo<T>(pub T);
Copy link
Member

Choose a reason for hiding this comment

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

I think it would be better to make the inner representation of the struct private and add AllowStdIo::new. This allows the internals to be changed if needed.

Also, could you addget_ref / get_mut / into_inner implementations for this type?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants