no_std Proof of Concept implementation

[pantsman0]

This is a start for supporting concread in no_std environments. While I am not working on it right now, this was motivated by my desire for a kv-store in a full featured, but non-std environment where the read-heavy hot path should basically never be slowed by writes locking the kv-store.

Most of this was just copy-paste drudgery adding trait bounds on lock_api's RawMutex or RawRwLock traits, but there may also be some gremlins about if you use the wrong combination of features (I took a lot of time to figure out which dependencies were rebuilding core/alloc in which combinations).

Unfortunately, there were also some dependencies that would build core+alloc with an alloc feature enabled even if std was also enabled, so consumers of the crate will have to enable the no_std feature if they want things to work properly.

[Firstyear]

Okay, so I've had a look and a bit of a minor clean up to make sure some tests work. This biggest hurdle here will be clippy and the type changes. The issue is by adding a lock parameter, every consumer of the library now needs to add lock parameters everywhere.

I'm wondering if we can do something like :

pub type BptreeMap<K, V> = BptreeMapRaw<K, V, M = crate::utils::DefaultRawMutex>

That way users of the library don't need to update every type annotation they made, but users who want to change the lock impl internally can.

[Firstyear]

we likely also should make some super traits to help in some places, as the trait bounds are really unwieldy in places

[pantsman0]

Okay, so I've had a look and a bit of a minor clean up to make sure some tests work. This biggest hurdle here will be clippy and the type changes. The issue is by adding a lock parameter, every consumer of the library now needs to add lock parameters everywhere.

I'm wondering if we can do something like :

pub type BptreeMap<K, V> = BptreeMapRaw<K, V, M = crate::utils::DefaultRawMutex>

That way users of the library don't need to update every type annotation they made, but users who want to change the lock impl internally can.

I'm totally fine with this. I think honestly if we're going to have the types be behind aliases, it might be worth removing the default parameters on the types. The the defaults can just be

#[cfg(feature = "std")]
pub type BptreeMap<K, V> = BptreeMapRaw<K, V, parking_lot::RawMutex>
#[cfg(not(feature = "std"))]
pub type BptreeMap<K, V> = BptreeMapRaw<K, V, spin::mutex::SpinMutex<()>>

ARCache can have the same thing for the RawRwLock definition too. I'm not sure if there's really any reason to have a default parameter if consumers only interact with the Raw type when that generic is being overridden.

[pantsman0]

OK, so I've gone through and I've actually removed the default type provided for no_std environments. If a consumer is using it without linking std, it is probably actually better for them to be forced to decide on a synchronization mechanism rather than have a spinlock provided transparently.

[pantsman0]

@Firstyear sorry mate. I have a build with the lifetime flow fixed for the Miri build. Do you want it pushed up tonight or so you want to do it?

[Firstyear]

I think this looks good, the question is if we want to do the type aliases here or not - When I test against existing projects I get lots of missing parameter warnings/errors, and I would like to avoid that for users to make their upgrades easier. The big one is in external projects if they use say ARCacheWriteTxn in a return type or argument type, then suddenly they have to add a lot of extra parameters.

The negative is our types end up pretty messy with lots of aliases and long names, but it's maybe worth it. What do you think?

[pantsman0]

I am happy to do some type aliases for users. Can you provide an example of a consumer where I can see the build error? I can see what I can do from there.