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.
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 usingco_is_expired()to checknowagainst a timestamp and fixed period, this should be easily implemented by returning the time left fromco_is_expired()and propagating the minimum value up the call chain toco_main()which can re-arm the timer.Then also the
CO_JOB_PERIODICmessage must be force sent whenever any event causes a timer to be set, to recalculate the timeout. Maybeco_handle_periodic()can be called every iteration of theco_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.