Skip to content

Make async-std optional #246

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

Merged
merged 4 commits into from
Oct 10, 2020
Merged

Make async-std optional #246

merged 4 commits into from
Oct 10, 2020

Conversation

akhilles
Copy link
Contributor

closes #244

Copy link
Member

@yoshuawuyts yoshuawuyts left a comment

Choose a reason for hiding this comment

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

Two small nits on coding style that I'd like to see applied to the entirety of the patch; but otherwise a 💯 change!

src/body.rs Outdated
@@ -160,7 +159,7 @@ impl Body {
/// # Examples
///
/// ```
/// # fn main() -> Result<(), http_types::Error> { async_std::task::block_on(async {
/// # fn main() -> Result<(), http_types::Error> { futures_lite::future::block_on(async {
Copy link
Member

Choose a reason for hiding this comment

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

Instead of relying on block_on (which futures_util does not have), these should move to using #[async_std::main]

Suggested change
/// # fn main() -> Result<(), http_types::Error> { futures_lite::future::block_on(async {
/// # #[async_std::main]
/// # async fn main() -> Result<(), http_types::Error> {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replaced with async_std::task::block_on since that was already being used.

Copy link
Member

Choose a reason for hiding this comment

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

These should still be moved to #[async_std::main], either in this PR or in another.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Using #[async_std::main] does increase compile times though. It's probably better to make that change in a separate PR.

Copy link
Member

Choose a reason for hiding this comment

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

Ah I suppose we may want to leave the hidden ones as is then...

@Fishrock123 Fishrock123 dismissed their stale review September 27, 2020 00:35

comments have been addressed

@jbr
Copy link
Member

jbr commented Oct 3, 2020

This looks good. Is it semver-major?

@akhilles
Copy link
Contributor Author

akhilles commented Oct 4, 2020

This looks good. Is it semver-major?

I don't believe so.

@akhilles
Copy link
Contributor Author

futures-lite now has a prelude, updated the imports to use it.

jbr
jbr previously requested changes Oct 10, 2020
Copy link
Member

@jbr jbr left a comment

Choose a reason for hiding this comment

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

I'm excited to get this merged, but have concerns about the change in async channel semantics regarding send errors and closed channels

///
/// Unlike `async_std::sync::channel` the `send` method on this type can only be
/// called once, and cannot be cloned. That's because only a single instance of
/// `Connection` should be created.
#[must_use = "Futures do nothing unless polled or .awaited"]
Copy link
Member

Choose a reason for hiding this comment

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

Is this comment no longer relevant? Why was it removed?

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 the receiver, the comment was meant for the sender I assume.

Self { sender }
}

/// Send a `Trailer`.
///
/// The channel will be consumed after having sent trailers.
pub async fn send(self, trailers: Connection) {
self.sender.send(trailers).await
let _ = self.sender.send(trailers).await;
Copy link
Member

Choose a reason for hiding this comment

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

This line seems worth discussing. async-std channels cannot be closed as long as there's a sender, but async-channels can be, and return an Err variant if the channel is closed. Probably the best fix for this is to return that Result, making this semver-major. As written, this silently swallows the possible SendError.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Functionally, this is the same as existing behavior. It's a oneshot channel where the sender doesn't care if the receiver is dropped. It might be a good idea to return a Result here if the receiver has been dropped, but I see it as a separate issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since this Sender/Receiver code is duplicated a couple times, I'd recommend making a generic oneshot submodule that's shared by trailers, upgrade, and whatever else relies on this pattern.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was planning that as a follow-up, but I wanted to keep this PR non-breaking.

@jbr jbr dismissed their stale review October 10, 2020 21:39

concern about behavior with closed channels addressed

@jbr jbr merged commit 4165546 into http-rs:main Oct 10, 2020
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.

Make async-std dependency optional
4 participants