* Fix uds listener hanging on accept
UDS listener was hanging because the accept method would return
`Poll::Pending` without registering the task to be awoken in the case
when underlying unix listener returns a WouldBlock that gets converted
to None. This is a hacky fix for this case.
Should fix#248
* Test simulating uds ping-pong server/client
This one should reproduce #248 bug to prevent further regressions.
* Code review fixes
282: init path submodule as unstable r=yoshuawuyts a=yoshuawuyts
Ref #183.
Similar to #257 this adds the `path` submodule as unstable. Filling in all re-exports from std for module completion. From there the we can build out `Path` and `PathBuf` accordingly. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
266: Changes Extend trait in order to allow streams that yield references r=yoshuawuyts a=sunjay
This is not ready to merge yet. I am mainly opening it so we can discuss a change I had to make to the `Extend` trait. cc @yoshuawuyts @stjepang (and anyone else interested)
## Before this can be merged
- [x] Discuss/Approve changes to `Extend` trait
- [x] Change to using `for_each` after #264 is merged
- [ ] (optional) Wait until a `copied()` method is added to `StreamExt` so that the `&char` impl can be finished.
- We can also just comment out or remove the impl that uses `copied` until that is added
## Changes To The Extend Trait
While writing the impls of the `Extend` trait for the `String` type, I noticed that certain impls weren't possible because there is no bound on `Extend` that guarantees that the type `A` being yielded from the stream actually lives long enough. We probably didn't run into this earlier because this usually isn't a problem for owned values since the compiler doesn't have to worry about whether they will out live the stream that they come from. I ran into this because of the `Extend` impls that consume streams of references.
The difference between the async `Extend` and the standard library `Extend` is that the async `Extend` returns a value that still references the input stream. That means that if `A` is any reference type, the compiler needs to be able to guarantee that `A` will be around as long as the `Future` returned from the trait method is around.
To fix this, I had to add the bound shown below:
```patch
pub trait Extend<A> {
/// Extends a collection with the contents of a stream.
fn stream_extend<'a, T: IntoStream<Item = A> + 'a>(
&'a mut self,
stream: T,
- ) -> Pin<Box<dyn Future<Output = ()> + 'a>>;
+ ) -> Pin<Box<dyn Future<Output = ()> + 'a>> where A: 'a;
}
```
This guarantees that each value of type `A` will last at least as long as our boxed future does. The bound had to be in a where clause on the method (and not on the declaration of `A` because the lifetime `'a` isn't in scope at the trait level. I don't think there are any negative consequences of using a where clause like this, but that's why I wanted to bring it up for discussion.
In addition to this, I had to ensure that when writing the `Extend` impls for `String` I appropriately bounded the lifetime of the references from the stream. You can see this in the code below with `where 'b: 'a`.
```rust
impl<'b> Extend<&'b str> for String {
fn stream_extend<'a, S: IntoStream<Item = &'b str> + 'a>(
&'a mut self,
stream: S,
) -> Pin<Box<dyn Future<Output = ()> + 'a>> where 'b: 'a {
//TODO: This can just be: stream.into_stream().for_each(move |s| self.push_str(s))
Box::pin(stream.into_stream().fold((), move |(), s| self.push_str(s)))
}
}
```
I should note that initially I tried to make it work with just the impl shown above, without modifying the `Extend` trait. This doesn't work because it would be a stricter bound than what is found in the trait itself. Rust does not allow stricter bounds like that because it could potentially cause unsoundness when dealing with generics.
Of course, I am totally open to being completely wrong in my understanding of how to resolve this issue. I tried to solve the problem with as minimal of a change as possible. Please let me know if you have some better ideas or other suggestions.
## `FromStream` impls for String
The purpose of adding these `Extend` impls is to continue my work from #129 in adding the rest of the `FromStream` impls. The `Extend` impls are used directly to add all of the `FromStream` impls for `String`. Just like with #207 and #265, this adds a new `string` module that is unstable just like the other modules added for `FromStream`.
Co-authored-by: Sunjay Varma <varma.sunjay@gmail.com>
241: Simplify extension traits using a macro r=yoshuawuyts a=stjepang
This PR would fix#235
Async methods in our extension traits are now written in the simpler `-> impl Future<Output = T> [ConcreteFuture<Self>]` style. At the same time, doc tests are used even when the `docs` feature is not enabled.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
224: Re-export IO traits from futures r=stjepang a=stjepang
Sorry for the big PR!
Instead of providing our own traits `async_std::io::{Read, Write, Seek, BufRead}`, we now re-export `futures::io::{AsyncRead, AsyncWrite, AsyncSeek, AsyncRead}`. While re-exporting we rename them to strip away the "Async" prefix.
The documentation will display the contents of the original traits from the `futures` crate together with our own extension methods. There's a note in the docs saying the extenion methods become available only when `async_std::prelude::*` is imported.
Our extension traits are re-exported into the prelude, but are marked with `#[doc(hidden)]` so they're completely invisible to users.
The benefit of this is that people can now implement traits from `async_std::io` for their types and stay compatible with `futures`. This will also simplify some trait bounds in our APIs - for example, things like `where Self: futures_io::AsyncRead`.
At the same time, I cleaned up some trait bounds in our stream interfaces, but haven't otherwise fiddled with them much.
I intend to follow up with another PR doing the same change for `Stream` so that we re-export the stream trait from `futures`.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
209: add feature guards for unstable features r=yoshuawuyts a=yoshuawuyts
Makes sure unstable features aren't accidentally usable without their corresponding flags. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
167: add io::cursor r=stjepang a=yoshuawuyts
Adds `io::Cursor` and makes it so `io::prelude::*` behaves the way it does in std (so it can actually be implemented - though this might just have been a bug on my side??).
Ref #131. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
207: Added the ability to collect a stream of results r=yoshuawuyts a=sunjay
As requested here: https://twitter.com/yoshuawuyts/status/1174026374316773377
The standard library has a very useful implementation of `FromIterator` that takes an iterator of `Result<T, E>` values and is able to produce a value of type `Result<Vec<T>, E>`. I asked for this in `async-std` and @yoshuawuyts recommended that I contribute the impl. It turns out that the implementation in the standard library is even more general than I initially thought. It allows any collection that implements `FromIterator` to be collected from an iterator of `Result<T, E>` values. That means that you can collect into `Result<Vec<T>, E>`, `Result<HashSet<T>, E>`, etc.
I wanted to add a similarly generic impl for this crate so we can also support collecting into any collection that implements `FromStream`.
The implementation for this is based heavily on [what exists in `std`](9150f844e2/src/libcore/result.rs (L1379-L1429)). I made a new `result` module since that's where this impl is in `std`. I still wanted to maintain the conventions of this repo, so I copied the `vec` module that @yoshuawuyts created in #125. Much like in that PR, the new `result` module is private.
There is a doctest in the documentation for `collect` that both teaches that this feature exists and tests that it works in some simple cases.
## Documentation Screenshot
Co-authored-by: Sunjay Varma <varma.sunjay@gmail.com>
40: Add initial Fuse implementation for Stream r=yoshuawuyts a=spacejam
@matklad does this address your use case?
Co-authored-by: Tyler Neely <tyler.neely@ferrous-systems.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
205: Implement simple work stealing r=yoshuawuyts a=stjepang
This is our first version of a work-stealing scheduler. We won't stop here, there is still lots of room for improvement.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
180: adds stream::fold combinator r=stjepang a=montekki
Fold. Kind of clumsy around the part with the option and moving out of the shared context.
___
Stdlib: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.fold
Ref: #129
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
203: expose std::pin r=yoshuawuyts a=yoshuawuyts
This is important when defining / calling futures, so it makes sense for us to also export this.
But also given recent user feedback on the confusion on pinning, I'd like to open up the possibility to experiment with providing better pinning facilities such as [`pin-project`](https://github.com/taiki-e/pin-project) or [`pin_mut`](https://docs.rs/pin-utils/0.1.0-alpha.4/pin_utils/macro.pin_mut.html) behind flags. I'm not sure if we could, or even should. But I want to allow us to have that conversation and test things out (even if it's just in floating patches.)
Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
190: Clean up the fs module and a few other places r=stjepang a=stjepang
Just a cleanup for various pieces of documentation, mainly around the `lib.rs` docs, the prelude, and the `fs` module. Some small bugs are also fixed along the way.
This PR is the first one in a series of review PRs that I will be submitting before the upcoming 1.0 release.
200: expose IoSlice, IoSliceMut r=stjepang a=yoshuawuyts
Exposes `io::IoSlice` and `io::IoSliceMut`. Given we're returning these from `read_vectored` and `write_vectored` it might make sense to just include them as part of our re-exports. Thanks!
Ref #131.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
