Would you mind elaborating a bit on the rationale for doing this by cfg-gating out the atomic structures on these targets, rather than using something like portable-atomic, which we use elsewhere?

For the record, I'm not suggesting that just disabling these APIs on non-CAS platforms is the wrong approach, I'm just curious about why it's the right one. My guess is that this is because portable-atomic's fallback on these platforms is a mutex-like thing, making the lock free structures suddenly...not lock-free, and hand-implementing a critical-section/mutex-y version of the structure would allow better control of where critical sections occur etc?

My guess is that this is because portable-atomic's fallback on these platforms is a mutex-like thing, making the lock free structures suddenly...not lock-free, and hand-implementing a critical-section/mutex-y version of the structure would allow better control of where critical sections occur etc?

Yep! That's exactly it. A naiive "drop in p-a" impl would be decidedly not-great for all structures, so my plan was to make the current lib build, notching out unsupported structures entirely, then in a second pass/PR, re-implement at least TransferStack, providing a pretty much separate (but API compatible!) implementation that uses a larger critical section when interacting with the list. This way, we have a single, sliiiightly larger, critical section, rather than a couple of smaller ones.

For what it's worth, bbqueue (the stable version) went the p-a route, and I realized that it was unsatisfying, because it meant doing multiple separate critical sections for ringbuffer ops (emulating the atomic lock-free algorithm).

For bbq2, I ended up making a separate trait for Coordination, though I'm not sure whether that's the route to go for in TransferStack. That's why I wanted to land this PR first, to first discuss "is it a good idea to support non-atomic targets" (and a little bit "are we okay with not always supporting non-atomic targets 1:1"), and the next PR can discuss "is this specific impl of TransferStack a good way to do so".

Yeah, that makes sense. I'm on board with the initial goal of just getting the crate to build for those targets at all!

@hawkw is this good to merge, or did you want to take another pass on it?

@hawkw is this good to merge, or did you want to take another pass on it?

sorry, i wanted to leave a few suggestions on the feature-flagging implementation. give me a sec!