Serge Barral

Follow-up: I wonder if this might be related to https://github.com/tokio-rs/loom/issues/249 because the assertion does succeed when a `yield_now()` is inserted before the RMW.

I simplified somewhat the test to make sure this was not Mutex-related: ```rust loom::lazy_static! { static ref LOCK: AtomicU32 = AtomicU32::new(0); static ref DATA: AtomicU32 = AtomicU32::new(0); static ref OBSERVED:...

I could indeed reproduce this, but I have a theory: I suspect this might happen if the call to `waker.wake()` happens while the task is being concurrently woken by the...

Funnily enough I have just noticed that PR https://github.com/smol-rs/async-channel/pull/16 (which was never merged) does exactly what I suggested above, so in theory the PR already exists :-) Its motivations were...

Also, I failed to mention this but a similar issue exists when receivers are forgotten, and PR https://github.com/smol-rs/async-channel/pull/16 fixes this as well.

So I went ahead with a fresh PR since the old one had conflicts and anyway I wanted to add tests to confirm that it closes this issue.

Here are the results of the only benchmark that showed significant enough differences. This benchmark is a beast so I can't really share it easily (I made it for my...

> @sbarral Do you have any other benchmarks, e.g. basic SPSC or MPSC? I'd like to make sure this PR doesn't regress the common case before I merge it. The...

I think this can be closed now that PR #49 has been merged.

Sorry to hear about that, indeed rust jobs are not plentiful yet sadly... I decided to bite the bullet and write my own reusable one-shot channel. Guaranteeing truly lock-free send,...