Taiki Endo

I would accept a PR to support loom in a similar way as https://github.com/crossbeam-rs/crossbeam/pull/487.

It seems https://github.com/tokio-rs/loom/issues/133 has been resolved.

If we do this, it would be a breaking change because it would change types that implement `Source `. And the new version force downstream to use `AsFd`/`AsSocket`. Right?

I'm okay with adding this, but there are some safety issues to keep in mind when implementing/reviewing. Actually, some of the major (Mutex|RwLock)::map implementations were unsound. https://github.com/tokio-rs/tokio/issues/3344, https://github.com/rust-lang/futures-rs/issues/2239, https://github.com/Amanieu/parking_lot/issues/259, https://github.com/Amanieu/parking_lot/issues/258

I think a caveat like "calling this method on async code may cause deadlock" would be nice. Otherwise LGTM. > I wonder if this could be done for async-channel, since...

Since async-net already depends on socket2 via async-io, this could probably be implemented in a way that wraps socket2. (Most of the work probably needs to be done on the...

The current behavior is what was intended by the original author of this crate. https://github.com/rust-lang/futures-rs/issues/1987#issuecomment-661028051 > since this crate is supposed to be fully compatible with the futures crate Full...

This should be possible to do by applying a patch similar to https://github.com/crossbeam-rs/crossbeam/commit/06d77d35ce7165f04d7027608a99331a2e3e0f9c to [concurrent-queue](https://github.com/smol-rs/concurrent-queue).

I think the current implementation is wrong in 2 ways. - It should use `fuse` to avoid polling after the underlying stream returns `None` as it can cause panic. -...

- This adds a dependency on a lot of unsafe code that doesn't seem to be documented at all. - Since futures-micro's major version is less than 1, it is...