Ibraheem Ahmed

@rc-andres was your case using a similar thread priority setup?

See https://github.com/rust-lang/rust/issues/112723#issuecomment-1657002214, I think it's unlikely that `try_recv` can be truly non-blocking.

Running on the https://github.com/crossbeam-rs/crossbeam/pull/1105 branch I no longer see any long `try_recv` calls. @benhansen-io and @rc-andres can you confirm that the PR fixes your issue?

`send_silent` might be a good name for this.

I'll try to post some relevant benchmark/profiling results to see how much this helps.

I ran the benchmarks locally and there are some large performance regressions, especially on the spsc benchmarks. However, I'm not we should be optimizing for those benchmarks as opposed to...

We probably also want to introduce a non-linearizable version of `try_recv`, because this doesn't actually fix the issue of `try_recv` taking longer than expected.

Here are the benchmark results before and after. Note that all of the fallback cases are very unlikely to be hit on most setups, so this is just measuring the...

The `SeqCst` throughout crossbeam-channel is necessary to establish a total order between send/recv and `is_empty`. Without it the optimistic check in https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-channel/src/waker.rs#L222 would be incoherent.

I'm working on an idea that should hopefully fix a lot of these related issues.