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

More efficient timeout implementation #6

Open
nattgris opened this issue Feb 13, 2020 · 0 comments
Open

More efficient timeout implementation #6

nattgris opened this issue Feb 13, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@nattgris
Copy link

It's a bit inefficient to poll the stack for its timeout handling at 1 kHz.

Suggestion from #3:

It would be nice if the clients of the periodic job feature could say when they are expiring, so that the timer can be armed to the time required instead of periodically. Since all callees in co_handle_periodic() seems to end up using co_is_expired() to check now against a timestamp and fixed period, this should be easily implemented by returning the time left from co_is_expired() and propagating the minimum value up the call chain to co_main() which can re-arm the timer.

Then also the CO_JOB_PERIODIC message must be force sent whenever any event causes a timer to be set, to recalculate the timeout. Maybe co_handle_periodic() can be called every iteration of the co_main() loop to cover all cases where the event passes trough the main thread? Are there others?

The main loop could probably even use the timeout feature of os_mbox_fetch() to wake up at the right time instead of keeping a separate timer around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants