mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-04 03:11:58 +00:00
3f55dafebc
The only difference between this call and k_thread_abort() (beyond some minor performance deltas) is that "cancel" will act as a noop in cases where the thread has begun execution and will return an error. "Abort" always succeeds, of course. That is inherently racy when used as a "stop the thread" API: there's no way in general (or at all in SMP situations) to know that you're calling this function "early enough" to catch the thread before it starts. Effectively, all k_thread_cancel() gives you that k_thread_abort() doesn't is an indication about whether or not a thread has started. There are many other ways to get that information that don't require dangerous kernel APIs. Deprecate this function. Zephyr's own code never used it except for its own unit test. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| data_passing | ||
| memory | ||
| other | ||
| overview | ||
| synchronization | ||
| threads | ||
| timing | ||
| usermode | ||
| kernel.rst | ||