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

Fixed low-repro reset bug. #1970

Closed

Conversation

ironclownfish
Copy link
Contributor

Changed virtual void UpdatableObject::reset() to void UpdatableObject::reset(), and added a new function: UpdatableObject::resetImplementation(), which is called by UpdatableObject::reset().

reset() overrides always had to call super to get the base class functionality. Now the base class functionality is inherent in the reset() call. This allows the addition of a reset_in_progress flag in a single place, rather than in every reset() override. This new flag is used to make reset() reentrant, which fixes the bug.

Also removed all extraneous calls to super from reset() overrides (which are now resetImplementation() overrides). Moved other UpdatableObject reset/update failure cases into a virtual function: failResetUpdateOrdering(), so they can be disabled by overriding the function. This is a little cleaner, and the old way of disabling didn't work with the new reset stuff.

Nicholas Gyde and others added 9 commits April 15, 2019 15:14
Changed virtual void UpdatableObject::reset() to void UpdatableObject::reset(), and added a new function: UpdatableObject::resetImplementation(), which is called by UpdatableObject::reset().

reset() overrides always had to call super to get the base class functionality. Now the base class functionality is inherent in the reset() call. This allows the addition of a reset_in_progress flag in a single place, rather than in every reset() override. This new flag is used to make reset() reentrant, which fixes the bug.

Also removed all extraneous calls to super from reset() overrides (which are now resetImplementation() overrides). Moved other UpdatableObject reset/update failure cases into a virtual function: failResetUpdateOrdering(), so they can be disabled by overriding the function. This is a little cleaner, and the old way of disabling didn't work with the new reset stuff.
Changed virtual void UpdatableObject::reset() to void UpdatableObject::reset(), and added a new function: UpdatableObject::resetImplementation(), which is called by UpdatableObject::reset().

reset() overrides always had to call super to get the base class functionality. Now the base class functionality is inherent in the reset() call. This allows the addition of a reset_in_progress flag in a single place, rather than in every reset() override. This new flag is used to make reset() reentrant, which fixes the bug.

Also removed all extraneous calls to super from reset() overrides (which are now resetImplementation() overrides). Moved other UpdatableObject reset/update failure cases into a virtual function: failResetUpdateOrdering(), so they can be disabled by overriding the function. This is a little cleaner, and the old way of disabling didn't work with the new reset stuff.
@madratman
Copy link
Contributor

madratman commented May 18, 2019

this has some commits from your previous PR #1959 / #1925, probably as this PR is on the same AfricaTrackingFeature branch.. Can you rebase your local branch onto current upstream master?

@ironclownfish
Copy link
Contributor Author

this has some commits from your previous PR #1959 / #1925, probably as this PR is on the same AfricaTrackingFeature branch.. Can you rebase your local branch onto current upstream master?

Yeah I will sort that out. Gotta be less of a git n00b.

xmyqsh and others added 8 commits June 12, 2019 22:55
Fixed Cmakelists.txt for macos check
Changed virtual void UpdatableObject::reset() to void UpdatableObject::reset(), and added a new function: UpdatableObject::resetImplementation(), which is called by UpdatableObject::reset().

reset() overrides always had to call super to get the base class functionality. Now the base class functionality is inherent in the reset() call. This allows the addition of a reset_in_progress flag in a single place, rather than in every reset() override. This new flag is used to make reset() reentrant, which fixes the bug.

Also removed all extraneous calls to super from reset() overrides (which are now resetImplementation() overrides). Moved other UpdatableObject reset/update failure cases into a virtual function: failResetUpdateOrdering(), so they can be disabled by overriding the function. This is a little cleaner, and the old way of disabling didn't work with the new reset stuff.
Changed virtual void UpdatableObject::reset() to void UpdatableObject::reset(), and added a new function: UpdatableObject::resetImplementation(), which is called by UpdatableObject::reset().

reset() overrides always had to call super to get the base class functionality. Now the base class functionality is inherent in the reset() call. This allows the addition of a reset_in_progress flag in a single place, rather than in every reset() override. This new flag is used to make reset() reentrant, which fixes the bug.

Also removed all extraneous calls to super from reset() overrides (which are now resetImplementation() overrides). Moved other UpdatableObject reset/update failure cases into a virtual function: failResetUpdateOrdering(), so they can be disabled by overriding the function. This is a little cleaner, and the old way of disabling didn't work with the new reset stuff.
{
UpdatableContainer::reset();
UpdatableContainer::resetImplementation();
Copy link
Contributor

Choose a reason for hiding this comment

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

this does not look right to me, or maybe I am misunderstanding it
this looks like the anti-pattern itself

auto* sim_world_api = getWorldSimApi();
if (sim_world_api)
sim_world_api->reset();
else
getVehicleApi("")->reset();
resetInProgress = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

is this supposed to be scoped
don't quite understand why you need resetInProgress here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a previous hack fix that I thought I removed. (Maybe did, but who can tell with this commit history :| )

@@ -33,7 +33,7 @@ BuildAirsimWrapper()


###################### Link source files to library ######################################
if (${MACOSX})
if (${APPLE})
Copy link
Contributor

Choose a reason for hiding this comment

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

umm, no

@@ -13,7 +13,7 @@ class WorldSimApi : public msr::airlib::WorldSimApiBase
WorldSimApi(SimModeBase* simmode, std::string vehicle_name);
virtual ~WorldSimApi();
virtual bool isPaused() const override;
virtual void reset() override;
Copy link
Contributor

Choose a reason for hiding this comment

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

worlsimapibase.hpp has reset defined as pure virtual still..

@madratman
Copy link
Contributor

@ironclownfish see my partial review above..
Due to the irrevocable git blunders on this PR, I am closing this, and making a new one from my fork.

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

Successfully merging this pull request may close these issues.

5 participants