#![no_std] support

[AppCoder1234]

Hi,
Do you know if you plan for no_std support?
It would be really helpful, because I'm precisely looking for a lock-free, no_std slab storage
Looking at your crate, it does not seem like you use a lot of std-only features, I would venture saying maybe only no_std + alloc would be sufficient, and it would not be much overhead going no_std (I just don't know for the std::thread::panicking in panic_in_drop)
I can possibly help for the commit to support no_std
What do you think?

[hawkw]

Unfortunately, the sharding scheme this library uses relies on assigning an ID to each thread spawned by a program. This is implemented using a thread-local variable:

sharded-slab/src/tid.rs

Lines 40 to 42 in 8ebe120

	thread_local! {
	static REGISTRATION: Registration = Registration::new();
	}

Because threads are an abstraction provided by an operating system, there is no portable way to determine what concurrency context (e.g. CPU core) a slab is accessed in without using the standard library.

I would really like to be able to provide a version of this library that does support no-std uses. I think the way we would do this is by providing an abstraction for determining the current "concurrency context" (e.g. thread or CPU core). By default, this would be implemented to return the ID of the current thread. However, bare-metal users could provide an implementation of this interface that identifies a CPU core number or similar, using platform-specific features of the hardware they're targeting. This interface would, of course, be unsafe to implement, because an incorrect implementation could result in the same shard being mutated concurrently --- the library would rely on the implementation ensuring that each concurrency context always returns a unique ID.

Designing something like this would require some work, and I haven't really had the time to work on it. However, it is probably possible.

[AppCoder1234]

Ok thanks for the quick and detailed reply, I thought it would have been simpler
Do you know if there is any crate near the "concurrency context" abstraction that you mention in the crate ecosystem?
Maybe I can look at implementing something like that (a PID trait/interface), although I can't promise anything and would probably need some help/feedback along the way
Btw, do you want this issue to be closed?