time: Rename time_source_ and timeSource() to time_system_ and timeSystem() as appropriate #4343
Conversation
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
jmarantz
changed the title
|
This PR is has only mechanical renames, no re-organization or functional changes occurred. |
|
Are all three of your time-related PRs independent or is there any desired order of review/merging that will make people's lives easier? |
|
The 3 are independent, especially the one that adds simulated time. This one can be reviewed either before or after #4341 but after one is merged, I believe the other one will need a minor fix before it can be merged. |
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
|
It would be good to review this one soon if possible; the sooner it gets in, the less time dealing with merge conflicts. It's entirely mechanical. |
|
@htuch PTAL so you don't forget :) |
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Joshua Marantz <jmarantz@google.com>
|
Sorry about that; I had not scrutinized the diffs enough after sedding. Now I've made sure all declarations are consistent with variable names. Note that we still in places initialize a TimeSource& with a Event::TimeSystem&, which is fine as Event::TimeSystem inherits from TimeSource. |
| Runtime::RandomGenerator& random) | ||
| : local_info_(local_info), async_client_(std::move(async_client)), | ||
| service_method_(service_method), random_(random), time_source_(dispatcher.timeSource()) { | ||
| service_method_(service_method), random_(random), time_source_(dispatcher.timeSystem()) { |
There was a problem hiding this comment.
This one seems to still not match.
There was a problem hiding this comment.
WAI. The dispatcher keeps a TimeSystem because it works with timers. However, gRPC doesn't care about timers (yet) so it needs only a TimeSource. So when testing this, all you need is (say) a MockTimeSource, and don't need to set up a whole TimeSystem.
This is true with all the cases below as well.
| AsyncStreamCallbacks& callbacks) override; | ||
|
|
||
| TimeSource& timeSource() { return dispatcher_.timeSource(); } | ||
| TimeSource& timeSource() { return dispatcher_.timeSystem(); } |
| config_tracker_entry_( | ||
| admin.getConfigTracker().add("clusters", [this] { return dumpClusterConfigs(); })), | ||
| time_source_(main_thread_dispatcher.timeSource()), dispatcher_(main_thread_dispatcher) { | ||
| time_source_(main_thread_dispatcher.timeSystem()), dispatcher_(main_thread_dispatcher) { |
| service_method_(*Protobuf::DescriptorPool::generated_pool()->FindMethodByName( | ||
| "envoy.service.load_stats.v2.LoadReportingService.StreamLoadStats")), | ||
| time_source_(dispatcher.timeSource()) { | ||
| time_source_(dispatcher.timeSystem()) { |
3 participants
Description: In #4257, Event::TimeSystem was introduced to augment the TimeSource abstraction to include timers. Most places in the system that had previously held onto a TimeSource held it in a member variable time_source_ and, if appropriate, exposed it as a method timeSource(), and #4257 changed those to Event::TimeSystem without renaming them, in order to minimize diffs. This PR just renames the members and methods to time_system_ and timeSystem() as appropriate. This is part of the chain of CLs to resolve #4160.
Risk Level: low -- no functional risk, but depending on timing of when this gets merged, an easily-remedied build breakage could arise.
Testing: //test/...
Docs Changes: n/a
Release Notes: n/a