Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fix one typo (likes -> lives)

...

Under certain conditions, it may be necessary to create a kernel thread whose stack likes lives in some custom memory.  This page provides and example of how that would be done:

...

The effect of the TCB_FLAG_CUSTOM_STACK flag is the that the OS will not attempt to free the custom stack memory if the kernel thread exits, crashes, or is killed.  Does this matter in your implementation?  Could this result in some kind of memory leak?  If any kind of clean-up is required by your application to free the custom stack memory, you will probably want to use an on_exit() or atexit() function to get a callback when the kernel thread is terminated.

If TCB_FLAG_CUSTOM_STACK were not set in the TCB flags, the OS would attempt to free the stack using kmm_free() which is probably not what you want in this case.

The actual logic is a slightly more complex and somewhat redundant:

  • If TCB_FLAG_CUSTOM_STACK is set in the TCB flags, no attempt will be made to free the custom stack.
  • If TCB_FLAG_CUSTOM_STACK is not set in the TCB flags, the stack will be de-allocated for the kernel thread only if the stack lies in the kernel memory pool.

So in reality TCB_FLAG_CUSTOM_STACK may not be necessary.  But the safest option is to include it in all cases where you do not expect the custom stack to be de-allocated.

You must not free the custom stack after nxtask_activate() returns successfully and until the kernel thread is terminated.

...