WIP: Local Pool Refactoring #239
No reviewers
Labels
No Label
API Change
Breaking API Change
bug
build
cosmetics
Documentation
duplicate
feature
help wanted
hotfix
invalid
question
Refactor
Tests
wontfix
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fsfw/fsfw#239
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "KSat:mueller/LocalPoolRefactoring"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The current local pool implementation is still very similar to C code.
There are a lot of features in C++ which would make the handling a little bit more intuitive. Furthermore, the number of pool sizes does not really have to be a template.
I experimented with the local pool a long time ago (also to experiment whether C++ containers can be used instead of raw C arrays) and picked up on that again when I added a few features which could also be useful. I think the result is worth the effort and worth a pull request.
The pool is now configured by providing a reference to a multiset which contains pairs. The first value of a pair is the number of elements on a page and the second value is the size of the page. This logically groups data that belong together. Furthermore, being a multiset, the entries are sorted automatically by page size (custom comparator provided). Lastly, the number of pools can be derived by the number of pairs contained inside that multiset automatically. The pool containers itself are now vectors or nested vectors.
A big advantage is that no special destructor is necessary. Also, if i see correctly, no pointers are used anymore, so a pool can propably even be copied without providing custom (move) constructors (although I am not sure where this would be needed..)
Example (because this is also an API change unfortunately):
Old pool config:
New pool config:
I also added a few helper functions:
getFillCount
: Writes the fill count of each page and a median of the fill counts of each page in percent to a buffer.clearPage
: Clear a specific page of the poolgetTotalSize
: Calculates the full size allocated for the store itself and also calculates the size of the sizes container optionally.Pool Manager:
1
lockMutex
: Can be used by developer if lock needs to persist beyond a function call2.
unlockMutex
: ComplementAll changes were unit tested. I also tested it in our current mission code in general.
Unfortunately, unit tests don't exist yet for the EventManager and the PacketMatcher which use the pool too, but the test coverage of the unit tests is very high in any case. This also requires the new
FSFWConfig.h
file with the defineFSFW_DEBUGGING
defined.This is an API change (small though for developers). It would propbly be good to merge this after the first official release of the FSFW.
UPDATE: I will change this request to be merged into the new development branch
Local Pool Refactoringto WIP: Local Pool Refactoringsecond update: I will include unit tests written as well.
target into devel
Pull request closed