feat(task): Allow run_on_core
callers to ensure a separate task is created
#358
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.
Description
espp::task::run_on_core
(blocking) APIs to have abool ensure_task = false
parameter which (if true) will ensure that the function is run in a separate task, regardless of the requested core and current core id.espp::task::run_on_core
(blocking) APIs so thatcore_id = -1
(do not care) parameter will still spawn a separate task, instead of running in the same context as the calling function.Motivation and Context
The
espp::task::run_on_core
provides a convenient API for ensuring a function is run in a separate task (with its own stack) in a way that cleans up the memory and provides easy to read code. However, it was not great for guaranteeing that the requested stack is provided to the function, since there were conditions when it would run in the calling context (which may not have enough stack space).This PR addresses that by providing a new optional argument
ensure_task = false
which (if true) will force the function to run in a separate task, ensuring that the function is provided the requested stack in that case.This also makes the change that a don't-care core_id (-1) now no longer means that the function should run in the same thread-context as the caller. There's no benefit to that behavior since it doesn't guarantee anything about the execution core or the stack space available, so now a don't care (-1) core_id will ensure a task is spawned and the scheduler can decide the core to put it on.
How has this been tested?
Building and running
task/example
on a QtPy ESP32s3.Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):
Types of changes
Checklist:
Software
.github/workflows/build.yml
file to add my new test to the automated cloud build github action.Hardware