Open maribu opened 4 years ago
vTaskDelete()
is also anther function reinventing the sched_task_exit()
wheel.
The code is a bit tricky, but it was the only way to get it working with the existing API for ESPs.
Btw: Is there indeed a need to support two different ABIs?)
Yes, although ESPs are Xtensa cores, the ESP8266 uses the Call0 ABI while ESP32 uses the Window ABI. That's why ESP32 requires special handling on task_exit
.
The first n lines of the ESP32 task_exit()
and sched_task_exit()
do exactly the same: Updating the scheduler internals. Afterwards, sched_task_exit()
calls into the cpu code, namely cpu_switch_context_exit()
, while task_exit()
does other stuff.
Why wouldn't it be possible to just use sched_task_exit()
and move the other stuff from task_exit()
to cpu_switch_context_exit()
?
It might work. To be honest, I don't remember exactly why I did it in that way. I only remember that applications that return from the main thread did crash.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.
Description
The ESP32 and ESP8266 platform specific code is accessing scheduler internal stuff and writing to it. E.g.
NORETURN void task_exit(void)
is with__XTENSA_CALL0_ABI__
indeed just mapping toNORETURN void sched_task_exit(void)
, but otherwise is handling the task exit internally.IMO, we should make sure that platform specific code is not modifying the scheduler internal state. Instead, a well defined API should be used for interactions between platform specific code and the scheduler. This would allow changing the internals of the scheduler without breaking other stuff
Suggestion
Use existing scheduler API, such as
sched_task_exit()
Replace code writing to
sched_*
by calls to the existing scheduler API. E.g. rewrite thetask_exit()
function to also usesched_task_exit()
even when__XTENSA_CALL0_ABI__
is not used. (Btw: Is there indeed a need to support two different ABIs?)Or would this be infeasible to get the ESP platform working on top of the existing core APIs?
Extend the scheduler API
If indeed the current core APIs are not enough to get the ESP platform spinning, we should IMO just extend the APIs as needed and use that instead.
Versions
Current master