You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most tasks that receive and distribute events to callers have deterministic stack usage.
The stack for a task waiting on the event queue is at its lowest point.
The task receives an event and calls the handlers for that event one at a time.
The maximum task use is the maximum of the stack use of each handler.
This behavior makes it easy to reason about stack overflows; if we see an overflow we can find the one handler at fault.
Problem
An optimization in ErReturnToSender() in the FreeRTOS implementation causes the eventrouter to behave differently in a specific case.
This optimization saves a roundtrip for an event if the last subscriber lives in the same task as the sender; when the last subscriber is done with the event, the eventrouter returns the event to the sender immediately instead of reposting the event to the sending module's task's queue.
This only becomes a problem when the last subscriber:
Previously KEPT the event;
Lives in the same task as the sender; and
Calls ErReturnToSender() directly.
In this case we still have part of the subscriber's handler on the stack in addition to the sender's handler.
Conclusion
This shouldn't cause functional problems but may make stack overflows more difficult to diagnose and predict in some use cases.
The text was updated successfully, but these errors were encountered:
Standard Operation
Most tasks that receive and distribute events to callers have deterministic stack usage.
This behavior makes it easy to reason about stack overflows; if we see an overflow we can find the one handler at fault.
Problem
An optimization in
ErReturnToSender()
in the FreeRTOS implementation causes the eventrouter to behave differently in a specific case.This optimization saves a roundtrip for an event if the last subscriber lives in the same task as the sender; when the last subscriber is done with the event, the eventrouter returns the event to the sender immediately instead of reposting the event to the sending module's task's queue.
This only becomes a problem when the last subscriber:
ErReturnToSender()
directly.In this case we still have part of the subscriber's handler on the stack in addition to the sender's handler.
Conclusion
This shouldn't cause functional problems but may make stack overflows more difficult to diagnose and predict in some use cases.
The text was updated successfully, but these errors were encountered: