Pre-RFC: Investigate switching to intrusive waker lists by default about embassy HOT 3 OPEN

(UPDATED)

• Split out the RawMutex traits into a separate crate (embassy-sync-mutex, or something?), to allow for both embassy-sync and maitake-sync to rely on this

Splitting out RawMutex into its own micro-crate (ala embassy-time-driver and embassy-net-driver) - that is - if you decide against forking a subset of maintake-sync into embassy-sync - might have use-cases beyond your idea of re-using it in maintake-sync so that embassy-sync can depend on maintake-sync rather than fork it.

For example, that would give "easier time" to RawMutex implementor code that lives outside the embassy-sync crate. esp-idf-hal is currently such one, by providing two separate mutex implementations - one - based on "disable all interrupts (+ spinlocks for multi-core)" and another - based on regular FreeRTOS mutexes.

The thing is, the "one size fits all" approach of critical-section just does not work for traditional RTOSes, where you might need different types of blocking mutexes, depending on the context where you would like to use those. Abstracting by using RawMutex instead (and sure - by introducing generics that way) is one way to solve that in driver crates.

Currently, esp-idf-hal depends directly on embassy-sync, which is a bit painful. For example, our next release would be a breaking one, because embassy-sync currently went from 0.5 to 0.6. That's definitely not the only reason but could've been the only reason to issue a breaking release, which is not ideal.

from embassy.

Splitting out RawMutex into its own micro-crate (ala embassy-time-driver and embassy-net-driver) - that is - if you decide against forking a subset of maintake-sync into embassy-sync - might have use-cases beyond your idea of re-using it in maintake-sync so that embassy-sync can depend on maintake-sync rather than fork it.

Just confirming that I agree 100%! I didn't spell this out, but I definitely think this is a positive.

from embassy.

Regarding abstracting over raw mutex types, I would encourage investigating whether the lock_api crate can be used for that purpose --- it's pretty widespread in the non-embedded world, as parking-lot uses lock-api, but it also claims to have no-std support. I would look into whether its traits are suitable for our purpose. If they are, it's probably better to use the commonly-used trait rather than inventing a new version of it.

from embassy.