WIP: remove signal_fn in executor. #430
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The dynamic call into signal_fn here is rather slow (20-30 cycles). It would be cool to get rid of it.
However, it is needed to allow having multiple executors with different signal_fn's at the same time. For example, one WFE executor and one interrupt executor. It is not possible to use generics instead, as they would have to infect Executor, TaskStorage, TaskHeader, and we would still need a dynamic call when waking because now there can be multiple TaskHeader types. Not cool.
Solution: drop the possibility of mixing WFE and interrupt executors. This is not that big of a downside: if you want just one executor, use WFE. If you want multiple, just use all interrupt executors. YOu'll need to use up one extra hardware priority level, but these are usually plentiful.
(possibility of mixing could be added back by having ExecutorWaker store which kind it is and do an
if
. Not zero cost but probably still faster than a dyn call)TODO fix stm32, rp.
TODO add cargo features.