Taiki Endo

> So, I'm wondering whether it could help by actively contributing to crossbeam or not, in order to indicate my willingness to spend my time in exchange of my prs...

I'm thinking that if we put crossbeam-utils' atomic-related APIs behind a feature flag, adopt the approach I adopted in futures-rs (https://github.com/rust-lang/futures-rs/pull/2811), revert the edition bump (https://github.com/crossbeam-rs/crossbeam/commit/c5c1361e66897b56cfaa47c2f0f7a824cef11d2b, https://github.com/crossbeam-rs/crossbeam/commit/a57e655eef415c21babddc4ba0217b6ca7acd0a2), and disable unsafe_op_in_unsafe_fn...

> I didn't really like that this forced an unneeded dependency (`cfg-if`, mentioned at [smol-rs/cache-padded#10 (comment)](https://github.com/smol-rs/cache-padded/issues/10#issuecomment-1237286495)) onto my crate. Well, as for `cfg-if` I don't really like it and will...

> > Well, as for `cfg-if` I don't really like it and will eventually remove it. > > That's great news! Filed https://github.com/crossbeam-rs/crossbeam/pull/1072 for this. > > Do you have...

> > > Well, as for `cfg-if` I don't really like it and will eventually remove it. > > > > > > That's great news! > > Filed #1072...

Thanks for the PR. I guess this could be replaced by never + disconnect once the API for explicit disconnection is exposed?

I guess you want a variant of barrier that does not need to know the number of threads at construction, right? https://docs.rs/crossbeam-utils/latest/crossbeam_utils/sync/struct.WaitGroup.html#wait-groups-vs-barriers

Does std mpsc has the same issue?

cc @ibraheemdev

I think it may be related to extra spinning. What about when using std::sync::mpsc?