-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #274, NumOfChildTasks not decremented #485
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is sufficient to cover the issue. There are a few things here:
- Only covers child tasks that explicitly call
CFE_ES_DeleteChildTask()
. Does not cover tasks that exit themselves using e.g.CFE_ES_ExitChildTask()
. - It also assumes and does not confirm that
CFE_ES_DeleteChildTask()
is called by the another task within the same app. But the API description does not say this is a requirement - It just says it deletes a task specified by the task ID. It would be wrong to assume this.
I suggest an entirely different approach here. The issue is that it might not be possible to catch ALL cases of a task exiting so it is very challenging to keep a counter accurate here.
The only place that NumOfChildTasks
is actually used is part of the CFE_ES_GetAppInfo()
call which is generally only invoked from the QueryOne/QueryAll ground commands. It would be fairly easy to remove the counter from the global table entirely, which thereby solves the problem of keeping it up to date, and simply scan the app table as part of the CFE_ES_GetAppInfoInternal()
implementation itself; just loop through the app table and count the number of entries that have their MainTaskId equal to the AppId being queried. Of course this is slower but this is an infrequent call so I would think the complexity avoided by computing the value on-demand is better than optimizing a rarely-called function.
fsw/cfe-core/src/es/cfe_es_api.c
Outdated
if (Result != CFE_SUCCESS) | ||
{ | ||
CFE_ES_SysLogWrite_Unsync("CFE_ES_DeleteChildTask: Error calling CFE_ES_GetAppIDInternal for Task '%d'. RC = 0x%08X\n",(int)TaskId,(unsigned int)Result); | ||
ReturnCode = CFE_ES_ERR_CHILD_TASK_DELETE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should NOT return an error here. So long as the OS_TaskDelete returned success, that means the task is actually deleted. This is just an error with record-keeping. Fine to write to the syslog to document the inconsistency event, but the return code to the caller should still indicate the task was successfully deleted.
fsw/cfe-core/src/es/cfe_es_api.c
Outdated
@@ -1224,16 +1225,34 @@ int32 CFE_ES_DeleteChildTask(uint32 OSTaskId) | |||
if ( OSReturnCode == OS_SUCCESS ) | |||
{ | |||
/* | |||
** Get the AppID of the calling Application | |||
*/ | |||
Result = CFE_ES_GetAppIDInternal(&AppId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that CFE_ES_GetAppIDInternal()
returns the AppID of the calling context. So this assumes that this function will only ever invoked by the same App that created the child task in the first place. But this restriction is not documented in the API description of the CFE_ES_DeleteChildTask()
function.
If it is the intent to restrict this to the same app that owns the child task, then this should also be verified prior to doing the delete (i.e. make it an error to delete a child task associated with a different app) and note that restriction in the API documentation.
CCB 20200122 - Discussed, preference is to calculate on request and remove the counter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes to the FSW code look OK to me, but recommending a few changes to the UT test case.
Also as part of this I noticed duplicate storage of the tasks names which I noted in #502
fsw/cfe-core/unit-test/es_UT.c
Outdated
CFE_ES_Global.TaskTable[18].RecordUsed = true; | ||
CFE_ES_Global.TaskTable[18].AppId = 15; | ||
CFE_ES_Global.AppTable[15].AppState = CFE_ES_AppState_RUNNING; | ||
CFE_ES_Global.AppTable[15].TaskInfo.MainTaskId = 25; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test cases that write to specific fixed entries in the table should focus on the lower numbered entries (ideally just 0-4 if possible).
The size of the actual TaskTable is dependent on the OS_MAX_TASKS setting, and generally needs to be at least 5 to run CFE core tasks in the first place, but no guarantee it of anything beyond that.
fsw/cfe-core/unit-test/es_UT.c
Outdated
|
||
CFE_ES_GetAppInfo(&AppInfo,CFE_ES_Global.TaskTable[1].AppId); | ||
uint32 NumORegTasksTemp = CFE_ES_Global.RegisteredTasks; | ||
uint32 NumOChildTastTemp1 = AppInfo.NumOfChildTasks; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't the "NumOfChildTasks" here be a predictable/consistent number based on the previous TaskTable config? That is, I think we should know exactly how many child task entries are associated with the AppId because it was just set up earlier in the test sequence. If we do have a specific number which is the correct answer based on an explicitly set config, then we should assert for that specific number.
Also as a general style thing I think we try to avoid instantiating local variables in the middle of the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a correction to the previous review, mistakenly submitted as "approve" when it should have been "request changes". Just the UT bits noted in the previous review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not quite... see comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Real close now....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now!!
No longer keeps a running count of child tasks
Reset soft to master and checked in again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the approach of calculating this on the fly when needed.
CCB 20200212 - Approved |
Describe the contribution
Fixes #274, NumOfChildTasks not decremented
Testing performed
Steps taken to test the contribution:
Expected behavior changes
NumOfChildTasks will now be decremented when a child task is deleted.
System(s) tested on
Oracle VM VirtualBox
OS: ubuntu-19.10
Version: cFE 6.7.3.0; OSAL 5.0.3.0; PSP 1.4.1.0
Contributor Info - All information REQUIRED for consideration of pull request
Dan Knutsen
GSFC/NASA