Fix #978, put task parameters into task record #1151
Merged
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.
Describe the contribution
Encapsulate all parameters for apps and tasks into a structure object and clean up internal APIs to pass this object rather than individual parameters. These parameters can then easily be stored with the relevant record in the internal table (tasks, apps, libs) and makes management easier - as code copies one object rather than many individual fields with (potentially) different names.
All parameters are stored in the record, which facilitates future telemetry generation/stats and/or for when an app might get restarted or reloaded in the future.
Notably this changes all task startup to go through the same basic routine (there is no longer a need for different accounting between main tasks and child tasks) and share the same common entry point.
Fixes #978
Testing performed
Build and sanity check CFE. In particular ensure that all tasks + child tasks are starting and running normally. Also checked that the app restart command is working as expected.
Run all unit tests and confirm coverage.
Expected behavior changes
No public API change. Internal APIs are simplified, internal data structures are more consistent, and more detail is stored with the relevant record (i.e. task record has all relevant task details, so when looking up task info one does not have to traverse to the app record which previously held some of this data).
System(s) tested on
Ubuntu 20.04
Additional context
Using the common entry point for child tasks avoids a theoretical race condition where the child task might not have been fully accounted for in the global table at the time the user function started execution. Previously this would directly invoke the user-supplied function immediately. Now using the common entry point this delays until the task record is completely accounted for (linked back to app, etc) before calling the user function. So functions such as
CFE_ES_GetAppID()
and others will work right from the beginning.Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.