Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 3 additions & 5 deletions src/viam/sdk/module/service.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -116,12 +116,10 @@ struct ModuleService::ServiceImpl : viam::module::v1::ModuleService::Service {
"unable to reconfigure resource " + cfg.resource_name().name() +
" as it doesn't exist.");
}
try {
Reconfigurable::reconfigure_if_reconfigurable(res, deps, cfg);
res->set_log_level(cfg.get_log_level());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we no longer need the call to set_log_level?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch!


if (auto reconfigurable = std::dynamic_pointer_cast<Reconfigurable>(res)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If reconfigure_if_reconfigurable is going away, I think stop_if_stoppable should too. I don't think they are clearer than just using dynamic_pointer_cast.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

reconfigurable->reconfigure(deps, cfg);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⬇️

  • If we aren't going to address the issue where we construct a new resource before we have destroyed the old in this PR, let's ticket that work and add a TODO down around line 132 now. I think it is something of a priority.
  • Do we have any idea why the compiler wasn't able to flag everything after the block dealing with reconfigure as dead code? Actually, nevermind. I see it. If the code managed to throw something other than a std::exception, then it wasn't dead. Oops.

return grpc::Status();
} catch (const std::exception& exc) {
return grpc::Status(::grpc::INTERNAL, exc.what());
}

// if the type isn't reconfigurable by default, replace it
Expand Down
9 changes: 0 additions & 9 deletions src/viam/sdk/resource/reconfigurable.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -8,14 +8,5 @@ namespace sdk {
Reconfigurable::~Reconfigurable() = default;
Reconfigurable::Reconfigurable() = default;

void Reconfigurable::reconfigure_if_reconfigurable(const std::shared_ptr<Resource>& resource,
const Dependencies& deps,
const ResourceConfig& cfg) {
auto reconfigurable_res = std::dynamic_pointer_cast<Reconfigurable>(resource);
if (reconfigurable_res) {
reconfigurable_res->reconfigure(deps, cfg);
}
}

} // namespace sdk
} // namespace viam
8 changes: 0 additions & 8 deletions src/viam/sdk/resource/reconfigurable.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -15,14 +15,6 @@ class Reconfigurable {
/// @param cfg The resource's config.
virtual void reconfigure(const Dependencies& deps, const ResourceConfig& cfg) = 0;

/// @brief Reconfigures a resource if it is Reconfigurable.
/// @param resource the Resource to reconfigure.
/// @param deps Dependencies of the resource.
/// @param cfg The resource's config.
static void reconfigure_if_reconfigurable(const std::shared_ptr<Resource>& resource,
const Dependencies& deps,
const ResourceConfig& cfg);

protected:
explicit Reconfigurable();
};
Expand Down
14 changes: 8 additions & 6 deletions src/viam/sdk/resource/resource_manager.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -24,14 +24,16 @@ namespace sdk {
std::shared_ptr<Resource> ResourceManager::resource(const std::string& name) {
const std::lock_guard<std::mutex> lock(lock_);

if (resources_.find(name) != resources_.end()) {
return resources_.at(name);
auto res_it = resources_.find(name);
if (res_it != resources_.end()) {
return res_it->second;
}

if (short_names_.find(name) != short_names_.end()) {
const std::string short_name = short_names_.at(name);
if (resources_.find(short_name) != resources_.end()) {
return resources_.at(short_name);
auto name_it = short_names_.find(name);
if (name_it != short_names_.end()) {
res_it = resources_.find(name_it->second);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, this was a latent bug, in that the old code tried to look up the resource by short name a second time, rather than by using the "long name" it dug out of the short names map. Is that basically it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the original logic was correct, the issue was just that it was discarding the result of find and then calling at instead of keeping the iterator and dereferencing it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see I missed the at. OK, well, I agree this is better than the double lookups.

if (res_it != resources_.end()) {
return res_it->second;
}
}

Expand Down