Improve resource management and internal consistency in ES
jphickey opened this issue · comments
Is your feature request related to a problem? Please describe.
Executive Services (ES) maintains many internal tables of resources/objects, which track applications, libraries, tasks, counters, and memory pools, etc.
There is a lot of inconsistency in how these internal objects are managed/tracked. Some have a RecordUsed boolean that is set true/false depending on whether the record is used. App table uses the AppState member. The memory pool passes around direct pointers which are dereferenced (potentially dangerous).
Furthermore, all "ID" values issued to external apps are zero based, and therefore can easily alias other object types or even other objects of the same type. For instance, if one app had ID "5" and it was deleted, and after this a new/different app was started, the new app might also be assigned ID "5" ... this means any old/stale reference to AppID 5 will now be referring to the wrong app.
Describe the solution you'd like
Define a properly abstract "resource ID" type and use it consistently across all these various internal tables. The abstraction should be based on/compatible with what OSAL does for its internal records.
- The "id" value also serves as a marker to indicate whether the respective table entry is in use or not.
- Zero is reserved as an invalid value, and marks entries which are NOT in use. (e.g. so a
memset()to all zero can consistently clear an entry). Valid entries/ids are never zero. - Valid values are split into a "type" and sequential "index" value
- Type is unique for apps. libs, counters, etc so these cannot get crossed/misinterpreted (i.e. can't pass an appID in place of a libID or vice versa).
- Index is sequential and does not immediately repeat (i.e. don't wrap until 0xFFFF, do not recycle/reassign IDs after deletion).
- Provide a consistent mechanism to convert ID to a zero based index where an array/table is needed.
Additional context
This internal cleanup is a prerequisite to several related tickets:
- #28 - This blurs the difference between Libraries and Applications and makes the App API also apply to libraries, so they need a consistent means of identification and (possibly) make a single unified table.
- #651 - Need a better way to identify mem pools in CMD/TLM messages, not a direct address/pointer.
- #173 - More examples of ugliness/duplication of logic between apps and libs
Requester Info
Joseph Hickey, Vantage Systems, Inc.
Note - This came up in discussion in #28 -- split into a separate ticket as it probably warrants a separate review of its own.
@tngo67 - is this approach acceptable for your team? Mostly under the hood, but ends with a much more consistent implementation of ID's.
Yes! I vote for moving away from using array indices for IDs, at least for this specific issue, for reasons jphickey stated.