rust-embedded
Consider splitting concurrency (no pun intended)
https://rust-embedded.github.io/book/concurrency/index.html
is rather long and also contains enough interesting subjects to warrant a split in sub sections
My concern with splitting is that each section builds on the previous one to evolve gradually more and more checks and safety. The sections are not really standalone. Is the length especially a problem?
Well the building on the previous section is ok because
https://rust-embedded.github.io/book/intro/index.html
This book generally assumes that you’re reading it front-to-back
As i see it the following subjects are covered:
- The need (or no need) for concurrency (maybe the multi core caveat can be placed here)
- The problem of globally shared state
- The hardware solutions: atomics and temporarily disabling interrupts (critical sections)
- The helpful rust abstractions: Send & Sync and mutexes
- RTFM framework
- RTOS.
By the way now two C RTOS are mentioned, why not throw in a few rust RTOS as well ?
https://www.tockos.org/ https://zinc.rs/
My preference is to keep this unsplit as I think it makes it easier to read and follow, without having to click around navigation so much. I'd like to hear some other opinions though; I know many other sections are more split up.
We should at least link to TockOS. Zinc is deprecated and I don't think we should mention it.
I just read through the book yesterday, I also feel this chapter should be split, it is not a problem to navigate many pages, especially if I feel like every new page brings something to the table.
2023: I finished the chapter. Not thinking splitting as such would be the cure, alone. The chapter simply takes too many approaches, and turns out confusing.
