Prevent idle priority threads from potentially starving the FreeRTOS idle task #3909
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's new
This PR consists of three commits:
FuriThreadPriorityIdle
has been bumped down from1
to0
, to be on the same priority as the FreeRTOS idle task. This allows idle priority threads to spinloop (withfuri_thread_yield()
) and not starve that idle task, which apps like the Direct Draw debug app or Flipper95 were previously doing. This would manifest itself by qFlipper causing future USB connections to lock up until the offending application has been closed. With this change, the idle task is given enough time to process task deletions, and prevents the lockup.furi_thread_list_process
was made private, because it requires aruntime
parameter that can only be obtained from FreeRTOS.canvas_i.h
that wasn't needed, and made building with uFBT impossible until this include was removed.API version bump is needed because of
furi_thread_list_process
, but also because of the change to theFuriThreadPriority
enum.Fixes #3908
Verification
./fbt cli
. Observe that:Checklist (For Reviewer)