no_std + alloc

[jonhoo]

This crate should be possible to write using only core and alloc, and thus be usable in no_std environments.

The hashbrown implementation should be hugely helpful in figuring out how to do this. In particular, see the magical incantations in src/lib.rs and the use of alloc and core in src/raw/mod.rs. We may be able to simplify some of those since hashbrown has to pull some tricks so that it can be pulled into std. Compare for example with the no_std support in crossbeam-epoch/src/lib.rs.

There are a couple of things that we have to figure out how to operate in a no_std environment:

• crossbeam-epoch will need default-features = false and features = ["alloc"]. This will remove epoch::pin (but not epoch::Guard I think), and we'll need to figure out whether the API is still usable (and maybe include some examples).
• RandomState is only available with std, so we will want to add a std feature (which is on by default) and only expose it when the feature is enabled. We'll also have to figure out how that affects the default value for S.
• Neither num_cpus nor Once (which we use for NCPU) are available on no_std. We'll need to figure out how to determine the stride for transfers without it.
• We currently use std::thread::yield_now if we detect an initialization race. It's not entirely clear what we do in this case in a no_std environment. I think it is fine for us to use spin_loop_hint if the std isn't set for the following reason: for there to be a race, there must be another thread running concurrently with us. That thread cannot be blocked on us, since we are not in any mutually-exclusive section. So our goal is just to not waste cycles and give it some time to complete. It is not a requirement that we fully yield.

[GarkGarcia]

On regards to your second point, we could revert back to the old strategy in an no_std environment.

[GarkGarcia]

Started working on this in #44.

[jonhoo]

I'm going to close this for the time being, as we have no compelling use-cases, and the implementation ends up complicating the API a fair amount: #48. If someone does see a strong need for this and are willing to take on supporting this, then let me know and I'll re-open!