Closed bschwind closed 3 years ago
As a mental exercise, I have submitted #53 which could be (if finished) an alternative approach. It has both pros and cons. But I don't know whether there are some specific requirements, or perhaps some other work is depending on this - I'm cool with that experiment ending up being just ..an experiment. :)
@strohel I'd like to merge and release this PR for now, and have #53 be a replacement once the final design for it is settled. It'll be an extra semver bump but no big deal I suppose. I've already done quite a bit of testing for this PR on tonari's codebase and unfortunately I don't have a lot of time to do more for #53 yet.
@bschwind I see, cool. In fact, merging this removes any possible time pressure from #53, which is good.
With that in mind, the longer iteration time I introduce working on that sporadically should no longer matter, so let me try to iterate #53 further (unless you want to yourself, of course).
@strohel Ah yep, definitely no time pressure to get #53 working! I think overall you have some better ideas swirling around in your head for the implementation and I'm excited to see the final result of that. It'll feel less gross than this change for sure. We just had a fairly pressing need to remove all the thread::sleep()
calls we were using previously to schedule messages. tonari-actor
is now officially being used by tonari though, so yay to that 🎉
From #14
This feels a lot simpler than using
hierarchical_hash_wheel_timer
.It does the dumb thing which is to just keep a
Vec
of tasks and tick every millisecond (or a configurable timer resolution). It iterates over each task and runs if it has expired, and reschedules it if it's a recurring task.CPU usage is noticeably lower compared to
hierarchical_hash_wheel_timer
but it likely doesn't scale as well with lots and lots of timers in comparison.