Taiki Endo comments

Results 938 comments of


                                            Taiki Endo

Provide an `or!` macro that handles any number of futures

> a.or(b).or(c) I think such a chain is basically an anti-pattern because polling will become unfair. https://github.com/tokio-rs/tokio/issues/2319

future cannot be sent between threads safely the trait `std::marker::Sync` is not implemented for `dyn crossbeam::crossbeam_channel::internal::SelectHandle`

Please provide code to reproduce this.

future cannot be sent between threads safely the trait `std::marker::Sync` is not implemented for `dyn crossbeam::crossbeam_channel::internal::SelectHandle`

The situation of using crossbeam's select in async context seems odd to me: crossbeam's select blocks the current thread if all operations are not ready, which is basically bad behavior...

channel: Extend panic_on_drop test

bors r+

channel: Extend panic_on_drop test

bors r- asan reports memory leaks in added test

Add the ability to send/recv to/from the OS using polling, `WouldBlock` sys-calls

Why not use async? (It should already have the proper mechanisms to handle such cases.) > ```rust > if e.kind() == std::io::ErrorKind::WouldBlock { > dbg!("zzz"); > backoff.snooze(); > ``` It...

Support faster send/recv by not notifying the other side

Thanks for the PR! I think it's actually less-syscall, not syscall-free, but this could be more efficient when sending multiple messages continuously. However, we would need a clear caveat in...

Reduce backoff spinning/usage

Thanks! As for SPIN_LIMIT, I remember that 4 looked good when I looked into it before. https://github.com/taiki-e/crossbeam/commit/0362ffe0f5c7febcf9b8dac9db61547fd421546b That said, either is fine if performance is not that different.

Reduce backoff spinning/usage

The removal of double use of Backoff is definitely a non-controversial change. I think the others probably have different optimal solutions depending on the nature of the benchmark and the...

Potential deadlock and resource leak when `Receiver` is dropped in `crossbeam_channel`'s bounded channel

Same issue as https://github.com/rust-lang/rust/issues/107466? If so we just need to port its fix.