Closed jamesmunns closed 5 months ago
I think I have exactly the use case that needs this.
The main, fat rs-matter
structure is now const-initializable, yet it is not thread-safe (contains RefCell
s and Mutex<NoopRawMutex, ...>
stuff), that might or might not become configurable in future. I.e. use CriticalSectionRawMutex
or NoopRawMutex
depending on build features - yet - the single threaded model would remain the most appealing one.
Yet, I would really like to put it in a static context with static MATTER: SomethingSomething<Matter<'static>> = SomethingSomething::new(Matter::new(...))
, as this way (I hope) there would be no allocate-it-first-on-stack-and-then-move-into-rwdata-static` memory blolwups.
(Don't pay attention to the 'a
lifetime. It can be 'static
too, as the stuff that carries 'a
can also be const-initialized this way.)
btw @ivmarkov, you might like some of the "Generic over RawMutex" shenanigans I'm doing over in the new postcard-rpc
PR, to allow users to pick their mutex:
It looks like this at the device level:
@jamesmunns How about naming it StaticConstCell
instead?
(I considered StaticConstInitCell
too but that's a bit too long for my taste.).
Reasons:
StaticCell
and thus hinting that this guy is in a way a variation of the other; also matches closer the crate name itself@ivmarkov I don't love it! IMO the "const" part only applies at "init", the static itself isn't const. I don't feel that strongly about it if dirbaio prefers that tho.
ConstStaticCell
perhaps?
Released v2.1.0
This adds a "const initialized" variant of StaticCell.
I decided to add a second type, rather than extending StaticCell, because I couldn't see a way to do this without potentially making the value non-zero-initialized.
My other plan was to change the atomicbool into an AtomicU8 with three states:
But then one of the two flavors would have to start with a non-zero init value, which could "infect" the whole type into
.data
instead of.bss
.