#![no_std] support

[hawkw]

#![no_std] support

[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?