Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally process all triggered EventResponder events on a single yield() call #703

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

h4yn0nnym0u5e
Copy link
Contributor

Previous code required one yield() call for each triggered event in the list, potentially leading to high latency if many EventResponder objects are in use in a system with long intervals between calls to yield().

This update optionally changes that behaviour. The user can either:

  • use EventResponder::processAllEvents(true); to ensure every triggered event is processed on the next yield()
  • use a new triggerEventNextYield() function with the same syntax as triggerEvent() to get finer-grained control
    If the latter method is used, one event triggered using triggerEvent() will be responded to on each yield(), along with all events triggered by triggerEventNextYield().

This change also allows EventTypeYield responders to work in a manner consistent with EventTypeInterrupt ones, which are all run as soon as runFromInterrupt() fires.

As implemented, an event cannot be "promoted" to a "next yield" type if it was previously triggered by triggerEvent(), unless clearEvent() is called first.

Use triggerEventNextYield() to ensure the event will be responded to on the next yield().

Works by dividing the triggered event list into two sections; at the next yield() call, firstYield to nextYield will all be actioned, plus the first of nextYield to lastYield.

Also adds EventResponder::isActive() to determine if any EventTypeYield functions have been attached. This may be of use if users are finding yield() is slower than expected.

keywords.txt needs updating, but isn't in the scope of cores.
Untested, but the original code is near-identical between 4.x and 3.x so don't foresee any issues
Missing static class member - oops!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant