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

Set promise value after try-catch #1292

Closed

Conversation

brawner
Copy link
Contributor

@brawner brawner commented Sep 8, 2020

This PR fixes a potential issue, where promise->set_value is called before a potential call to promise->set_exception. Only one can be called, otherwise a std::future_error is thrown. This was the original ordering in #594, but it was rearranged in #738. @jacobperron @hidmic if this is breaking something unintentionally, please let me know. It should pass current unit tests as is. This patch is required in order to pass tests in #1290.

Signed-off-by: Stephen Brawner brawner@gmail.com

Signed-off-by: Stephen Brawner <brawner@gmail.com>
@brawner
Copy link
Contributor Author

brawner commented Sep 8, 2020

Testing current unit tests, --packages-select rclcpp_action

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@brawner
Copy link
Contributor Author

brawner commented Sep 9, 2020

Testing with unit tests introduced in #1290

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

Copy link
Member

@jacobperron jacobperron left a comment

Choose a reason for hiding this comment

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

Taking a step back, to me the promise pertains to the goal handle (which may eventually contain a result). Therefore, I don't think it makes sense to set an exception on the promise if there's an issue requesting the result, rather that exception should somehow manifest itself later when trying to access the result. Does that make sense?


promise->set_value(goal_handle);
if (options.goal_response_callback) {
options.goal_response_callback(future);
Copy link
Member

Choose a reason for hiding this comment

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

It was moved in response to #701 (review); if make_result_aware is called first, we risk having the result callback triggered before the goal response callback (unlikely, but I think this is possible if the action server is running in the same process).

Copy link
Contributor

@hidmic hidmic Sep 10, 2020

Choose a reason for hiding this comment

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

Hmm, reflecting on this, it seems to me that the goal response callback should simply be taking a concrete goal handle instead of a future one. Additionally, failing to make the goal handle result aware should not result in calling code losing access to the goal handle. Getting the future result should throw, but the exception could carry the goal handle (which is still valid) with it.

That's not a fix we can backport though.

Copy link
Member

Choose a reason for hiding this comment

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

@hidmic I agree with everything you've said. I think it's okay to not backport changes (though maybe we could by supporting two different signatures for the goal response callback).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adjusted the goal_response_callback signature, but I'm still not decided about what to do exception and goal handle bit.

Copy link
Member

Choose a reason for hiding this comment

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

I think we can remove the try-catch altogether. I'll open a PR in a moment with a proposed alternative.

Copy link
Member

Choose a reason for hiding this comment

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

See #1311.

Signed-off-by: Stephen Brawner <brawner@gmail.com>
@brawner
Copy link
Contributor Author

brawner commented Sep 15, 2020

Closing in favor of #1311

@brawner brawner closed this Sep 15, 2020
@clalancette clalancette deleted the brawner/rclcpp_action-set-value-after-exception branch January 15, 2021 16:33
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.

3 participants