Support for no_std? about left-right HOT 5 OPEN

Hi, sorry for the "delay" since the last activity on this. I now got the chance to take a look at the sento crate and I dont think that would currently fit into the approach here, as you cant get a "snapshot" of the currently acquired elements.

If I am not missing anything here, I will probably look into continue rolling a custom linked list here that supports the snapshots we would need or we could adapt the sento crate, but I am not sure that would be the right way about this.

from left-right.

After looking at the Code more closely, I also found that it uses the std::Mutex for epochs and I dont really know how we can adjust that without adding a new dependency like spin which I would like to avoid for now. Any ideas would be welcome

from left-right.

It'd definitely be nice if left-right could work in a no_std environment! For yielding, I think the function pointer approach is a good one. For the Mutex, I wonder if the way to go about it is the disallow creating a dynamic number of read/write handles, and instead have a constructor that takes a const generic <const R: usize> of the number of read handles to create, and then back it by an R-length array. The Mutex is only there to allow new handles to be added on the fly. Now, having both the dynamic and non-dynamic versions co-exist may end up being a little tricky, but I think it's probably doable.

from left-right.

Although the Array approach could definetly work I dont know if it may be too restrictive because you may not know how many readers there will be.
One quick thought I had was maybe using a "simple" lock free linked list, which could only grow or entries could be set to "free/vacant" to allow new read handles to pick them up again. This way we could have an unlimited number of Handles will still avoiding the Lock, however Im not sure if this would work with the writer as it can take like a "snapshot" and see all the read handles, but that may be fine because if a new one gets added while looking through the entries it should already see the new Pointer as well and therefore be save, but this definitely needs some more thought put into it.

Otherwise I could probably already start with some of the other changes and see how that looks in the meantime

from left-right.

Hmm, I think that could work, since the tail of the list still represents a snapshot. I'm imagining a lock free linked list where new ones are always added at the head — then to take a snapshot the writer simply reads the current head and iterates on the list from there and onwards. We may need to do some due diligence to make sure we get the right semantics, but on the surface it looks like a reasonable approach!

from left-right.