Josh Triplett

@Restioson I'd suggest two benchmarks: Thread-per-CPU and Single-threaded. (There are other possible configurations, but those will be the most common.) The actual benchmarks should be all the same things you...

You could call `.detach()` on them and use them exactly like you're currently using threads, just substituting `send_async().await` and `recv_async().await` in place of the send and recv calls, and then...

Thanks! I wrote some thoughts on what this could look like in https://github.com/bytecodealliance/cargo-wasi/issues/23#issuecomment-555843920 , with the aim of keeping the prebuilt binaries just as they are while making installs of...

@alexcrichton Awesome, thank you!

@stjepang That's doable. Could you live with it appearing as both `futures_lite::or_futures!` (or similar placeholder) *and* as `futures_lite::future::or!`? (The alternative would, as far as I can tell, require a separate...

Alright, I can try that. (It'd look a lot like this, but with the macro implementations moved to that helper crate, and then `pub use`d here.)

@jjl: I think the implementation of zip should pattern-match out of the nested 2-tuples, and emit an N-tuple. That isn't hard to do in a macro, and it would substantially...

I agree that it makes sense to not hide the await inside the macro. However, it also seems potentially confusing to have two `join!` macros that do subtly different things,...

@stjepang Sold. That makes perfect sense to me. That would allow `futures` to also add `zip!`, since it wouldn't conflict with the existing `join!`. And `futures-lite` can just *only* add...

@zeenix Rebased. @notgull Support for both blocking and non-blocking seems fairly fundamental to `event-listener`, and I think it's an important primitive for bridging between sync and async code. This is...