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

Update publisher creation/destruction API documentation. #252

Merged
merged 5 commits into from
Jul 28, 2020

Conversation

hidmic
Copy link
Contributor

@hidmic hidmic commented Jul 20, 2020

Precisely what the title says.

* Otherwise, it will proceed despite errors, freeing as many resources as it can, including
* the publisher handle. Usage of a deallocated publisher handle is undefined behavior.
*
* \pre Given node must be the one the publisher was registered with.
Copy link
Contributor Author

@hidmic hidmic Jul 20, 2020

Choose a reason for hiding this comment

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

This makes me wonder, why don't we keep a reference to the node in the publisher?

Copy link
Member

Choose a reason for hiding this comment

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

I understand what you mean, but I think the scope of that suggestion is a little broader than the goal of this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeap, not planning to address it here. Just wondering why we seemingly introduce a point of failure for no apparent reason.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure, but I think it might encourage the caller to make sure they keep the node around (as you need it to call fini on the publisher, so it's obvious it needs to be kept around), but I don't actually remember the logic behind it. Obviously if they just follow the docs, then this would not be a useful argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the insight. We can revisit at a later point in time. I wasn't planning to change it here anyways.

* arguments for now.
* This function can fail, and therefore return `NULL`, if:
* - node is not a valid non-null handle for this rmw implementation,
* as returned by `rmw_create_node()`, or it is associated to a shutdown context
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Behavior on a shutdown context was not specified. I think this makes sense.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if it makes sense.

One of the possible paths to fix ros2/rclcpp#1139 is to reduce the side-effects that calling shutdown has, and this will go against that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oof, that's a long winded discussion. Short term, I don't mind as long as behavior is specified.

Skimming through that thread though, this comment seems to suggest this is the current expected behavior, nevermind future changes.

Copy link
Member

Choose a reason for hiding this comment

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

Skimming through that thread though, this comment seems to suggest this is the current expected behavior, nevermind future changes.

I think that we have settled in that PR that we want to avoid that behavior in the future.

Currently, that behavior is only enforced in rcl in "some parts" of the API (not everywhere, some things continue working after shutdown).
IMO, we should avoid introducing similar checks in rcl, it will make change to happen much more difficult in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can settle over there, as I disagree with some of the arguments.

Copy link
Member

Choose a reason for hiding this comment

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

Sure, but this PR shouldn't be blocked waiting on that decision.
Currently, none of the rmw implementations are checking if shutdown has already been called.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair point. I do want to speed things up.

Copy link
Member

@ivanpauno ivanpauno left a comment

Choose a reason for hiding this comment

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

Some minor comments, otherwise LGTM

* arguments for now.
* This function can fail, and therefore return `NULL`, if:
* - node is not a valid non-null handle for this rmw implementation,
* as returned by `rmw_create_node()`, or it is associated to a shutdown context
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if it makes sense.

One of the possible paths to fix ros2/rclcpp#1139 is to reduce the side-effects that calling shutdown has, and this will go against that.

rmw/include/rmw/rmw.h Outdated Show resolved Hide resolved
rmw/include/rmw/rmw.h Outdated Show resolved Hide resolved
rmw/include/rmw/rmw.h Outdated Show resolved Hide resolved
* Otherwise, it will proceed despite errors, freeing as many resources as it can, including
* the publisher handle. Usage of a deallocated publisher handle is undefined behavior.
*
* \pre Given node must be the one the publisher was registered with.
Copy link
Member

Choose a reason for hiding this comment

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

I understand what you mean, but I think the scope of that suggestion is a little broader than the goal of this PR.

rmw/include/rmw/rmw.h Outdated Show resolved Hide resolved
@ivanpauno ivanpauno added the enhancement New feature or request label Jul 20, 2020
rmw/include/rmw/rmw.h Outdated Show resolved Hide resolved
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
@hidmic hidmic force-pushed the hidmic/update-publisher-docs branch from a02d3c3 to 06966ef Compare July 27, 2020 18:42
@hidmic hidmic requested review from wjwwood and ivanpauno July 27, 2020 18:42
@hidmic
Copy link
Contributor Author

hidmic commented Jul 28, 2020

CI up test_rmw_implementation against all RMW implementations:

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

@hidmic hidmic merged commit 163f070 into master Jul 28, 2020
@delete-merged-branch delete-merged-branch bot deleted the hidmic/update-publisher-docs branch July 28, 2020 22:03
ahcorde pushed a commit that referenced this pull request Oct 13, 2020
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
ahcorde pushed a commit that referenced this pull request Oct 13, 2020
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants