Clean-up the TCB at the right time. #359
Conversation
In the ESP32 port the current statement about clean-up TCB does not apply: ```c /* This call is required specifically for the TriCore port. It must be above the vPortFree() calls. The call is also used by ports/demos that want to allocate and clean RAM statically. */ portCLEAN_UP_TCB( pxTCB ); ``` Because it's not a tri-core port. What is actually useful is the ability to "release" an statically allocated TCB when a task is deleted. In order to do so, ```portCLEAN_UP_TCB``` can be used, but it needs to be called after all the accesses to the TCB are performed. In the current location, releasing the TCB causes a crash because the TCB is accessed by FreeRTOS several times afterwards. The proposed patch moves the call to the end and inside the check for a statically allocated TCB (where it makes sense).
|
To be sure I understand the motivation here: the cleanup work in this case will be a callback into the Micropython core, so Micropython's thread accounting knows this task no longer exists? |
Yes, it needs to free the memory for the stack and TCB itself for the thread that is being deleted. This memory is allocated on the uPy heap. You can't free the TCB memory until the very last moment because it's used by FreeRTOS to do the deletion of the thread. |
|
Do you mind sending this one as a new PR (or updating this PR) when you send the Kconfig item for enabling it as a feature? (If that makes things more difficult for you in terms of maintaining forks then we can merge this earlier, it just seems like they are closely related changes.) |
|
@projectgus OK, I'll create a new PR with this one and #358 plus the Kconfig changes included. Thanks. |
|
Sorry for the long delay. Superseded by: #444 |
In the ESP32 port the current statement about clean-up TCB does not apply:
Because it's not a tri-core port. What is actually useful is the ability to "release" an statically allocated TCB when a task is deleted. In order to do so,
portCLEAN_UP_TCBcan be used, but it needs to be called after all the accesses to the TCB are performed. In the current location, releasing the TCB causes a crash because the TCB is accessed by FreeRTOS several times afterwards. The proposed patch moves the call to the end and inside the check for a statically allocated TCB (where it makes sense).