Alisa Feistel

From my understanding, it's only supposed to be used ~~in macros~~ in macros and other crates inside this repo. So `#[doc(hidden)]` here, I'd expect, indicates the same thing as with...

yes, seems to be the same issue

`#[inline(always)]` on `clone_arc_raw` has some positive effect on the situation *sometimes* (`ref_wake_same` passes?)

I've tested it with `async-net` (versions `1` and `2`), and that worked okay; will test with `tokio` now; ed.: `tokio` is fine

This, to me, looks a lot like some sort of soft race condition, because it goes away if I add some overhead (or run the thing in `debug`) or do...

Update: this seems to affect anything that uses `async_io::Async::::poll_read` directly. Happens both on versions `1` and `2`

I found the reason (`async_tungstenite::compat`): ```rs let waker = match kind { ContextWaker::Read => task::waker_ref(&self.read_waker_proxy), ContextWaker::Write => task::waker_ref(&self.write_waker_proxy), }; ``` and the "fix" (for now I can't figure out much...

Okay, so I've added a print: ```rs let waker = match kind { ContextWaker::Read => task::waker_ref(&self.read_waker_proxy), ContextWaker::Write => task::waker_ref(&self.write_waker_proxy), }; eprintln!("{waker:?} {:?}", waker.clone()); ``` In debug builds (some parts omitted):...

There's been a change in how `Waker` works. `std::task::Wake` has adapted to it and `futures::task::ArcWake` has not. I've checked with both `std::task::Wake` and with a patched version of `futures::task::ArcWake`, both...

I'll list all the parts of code I found relevant so far in one place, ~~and with less guesses~~ `async-tungstenite` creating wakers that change their vtable on clone: https://github.com/sdroege/async-tungstenite/blob/6ff28b380c55b59a6ca96a6d76528754fa7b50ff/src/compat.rs#L128-L129 `async-std`...