Skip to content

Update publisher creation/destruction API documentation.#252

Merged
hidmic merged 5 commits intomasterfrom
hidmic/update-publisher-docs
Jul 28, 2020
Merged

Update publisher creation/destruction API documentation.#252
hidmic merged 5 commits intomasterfrom
hidmic/update-publisher-docs

Conversation

@hidmic
Copy link
Copy Markdown

@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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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.

* 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
Copy Markdown
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.

@ivanpauno ivanpauno added the enhancement New feature or request label Jul 20, 2020
hidmic added 4 commits July 23, 2020 18:28
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 ivanpauno and wjwwood July 27, 2020 18:42
@hidmic
Copy link
Copy Markdown
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