During test-dev and debugging of failing new test cases developed as part of PR #469 , the following code fragments were recognized as something that could be improved. In task.c we have the following globals:
11 int hook_init_done = 0;
12 static int num_hooks = 0;
13 static task_hook hooks[MAX_HOOKS];
These get initialized when task_system_create() calls register_init_tid_hook().
In some unit test cases developed under above-mentioned PR, we were doing task_system_destroy() followed by a re-creation of the task system using task_system_create(). task_system_destroy() destroys the task-system and releases its memory, but does not reset these global variables, especially the hooks[] array of functions.
At one point of test-dev, it appeared(*) that we were not invoking the thread-specific hook functions when new threads were created. Suspects were these globals, which was, eventually, found to be not the root cause.
The point of this issue is that we should still clean-up use of these globals and make them part of the task_system{} structure itself, so that these variable get setup and (properly) destroyed when the task-system is created / destroyed, respectively.
(*) It was later discovered to be a flaw in the test code due to a missing call to platform_thread_join() in the test case, which caused code-flow in the main thread to execute CTEST_TEARDOWN() which calls task_system_destroy().
--- Updated 30.Dec.2022: Although slightly unrelated, plan to do this cleanup after the rework of fg-/bg-threads that is in-flight under PR #497 hits /main. That may affect some of this area, so want to wait till those changes are finalized. Some of this hooks-business may be slightly reworked with that upcoming change.
During test-dev and debugging of failing new test cases developed as part of PR #469 , the following code fragments were recognized as something that could be improved. In
task.cwe have the following globals:These get initialized when
task_system_create()callsregister_init_tid_hook().In some unit test cases developed under above-mentioned PR, we were doing
task_system_destroy()followed by a re-creation of the task system usingtask_system_create().task_system_destroy()destroys the task-system and releases its memory, but does not reset these global variables, especially thehooks[]array of functions.At one point of test-dev, it appeared(*) that we were not invoking the thread-specific hook functions when new threads were created. Suspects were these globals, which was, eventually, found to be not the root cause.
The point of this issue is that we should still clean-up use of these globals and make them part of the
task_system{}structure itself, so that these variable get setup and (properly) destroyed when the task-system is created / destroyed, respectively.(*) It was later discovered to be a flaw in the test code due to a missing call to
platform_thread_join()in the test case, which caused code-flow in the main thread to executeCTEST_TEARDOWN()which callstask_system_destroy().--- Updated 30.Dec.2022: Although slightly unrelated, plan to do this cleanup after the rework of fg-/bg-threads that is in-flight under PR #497 hits /main. That may affect some of this area, so want to wait till those changes are finalized. Some of this hooks-business may be slightly reworked with that upcoming change.