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 node creation/destruction API documentation. #249

Merged
merged 6 commits into from
Jul 15, 2020

Conversation

hidmic
Copy link
Contributor

@hidmic hidmic commented Jul 7, 2020

Precisely what the title says.

* The security options should always be non-null and encapsulate the
* essential security configurations for the node and its entities.
* \pre The given name must be a valid non-null node name.
* \pre The given namespace_ must be a valid non-null node namespace.
Copy link
Contributor Author

@hidmic hidmic Jul 7, 2020

Choose a reason for hiding this comment

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

API here departs from the rest. Usually, a null argument means RMW_RET_INVALID_ARGUMENT or similar. rmw_create_node would do the same, and then require the caller to ensure name and namespace_ to be valid, precluding null arguments entirely.

I chose to keep the precondition. But we could check instead.

Copy link
Member

Choose a reason for hiding this comment

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

The problem of requiring preconditions that aren't checked at runtime and that the compiler doesn't check is that in the case they aren't satisfied it will probably generate a segfault (in no-release mode, that can be avoided using asserts).
If it's cheap to check, I don't see why not doing that.

Copy link
Contributor Author

@hidmic hidmic Jul 7, 2020

Choose a reason for hiding this comment

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

Asserts would indeed be required. That still means no checks in production.

If it's cheap to check, I don't see why not doing that.

I can't tell what the cost of validation is.


In this particular case, I don't mind either way as long as it's properly documented.

Copy link
Member

Choose a reason for hiding this comment

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

I can't tell what the cost of validation is.

Yeah, but it does sound like something we can do easily.

In this particular case, I don't mind either way as long as it's properly documented.

I think it was properly documented:

*   - context, name, namespace_, or security_options is `NULL`

Copy link
Contributor Author

@hidmic hidmic Jul 7, 2020

Choose a reason for hiding this comment

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

Correct, the odd thing being that nullity would be checked but validity would be assumed. Here I went for complete assumption. We can go for complete checking. It's the middle ground that I find odd.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See 6c83764 for the alternative.

Copy link
Member

Choose a reason for hiding this comment

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

Correct, the odd thing being that nullity would be checked but validity would be assumed. Here I went for complete assumption. We can go for complete checking. It's the middle ground that I find odd.

I didn't get that part before.
I imagine that for a valid name and namespace you're referring to:

I think we're using that on rcl but never on the rmw implementations (not sure why the definitions are in rmw, maybe we wanted to use the functions from the rmw implementations (?)).
Repeating the validity check would be probably unnecessary, as rcl already takes care of that.

It's the middle ground that I find odd.

Yeah, it's a bit odd to check "not NULL but maybe invalid".
I'm comfortable with the middle ground though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, I'm pushing for a choice because IMO the middle ground makes no sense. If the caller must ensure that names are valid, null names already fails validation. If you get a null name, that means the caller broke the precondition and you're in UB land. Checking for null doesn't make things any better.

If no one strongly disagrees, I'll keep the checks as it's less awkward.

* The security options should always be non-null and encapsulate the
* essential security configurations for the node and its entities.
* \pre The given name must be a valid non-null node name.
* \pre The given namespace_ must be a valid non-null node namespace.
Copy link
Member

Choose a reason for hiding this comment

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

The problem of requiring preconditions that aren't checked at runtime and that the compiler doesn't check is that in the case they aren't satisfied it will probably generate a segfault (in no-release mode, that can be avoided using asserts).
If it's cheap to check, I don't see why not doing that.

rmw/include/rmw/rmw.h Outdated Show resolved Hide resolved
Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

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

I've got a few more suggestions for clarification.

Comment on lines 138 to 141
* - context is not valid i.e. it has been initialized
* by `rmw_init()` but not yet invalidated by
* `rmw_shutdown()`
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I understand this sentence. Shouldn't it be more like:

 *   - context is not valid i.e. it has not yet been initialized
 *     by `rmw_init()` or has been invalidated by
 *     `rmw_shutdown()`

If not, can you clarify further?

Copy link
Contributor Author

@hidmic hidmic Jul 7, 2020

Choose a reason for hiding this comment

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

Yes! That's what I meant, though not initialized is a slippery slope. We can only safely guard against mismatching implementation identifiers or zero-initialized contexts. See 42bb43b.

@@ -166,10 +156,9 @@ rmw_get_serialization_format(void);
* \param[in] name the node name
* \param[in] namespace_ the node namespace
Copy link
Contributor

Choose a reason for hiding this comment

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

I know you didn't change this, but I find it odd that namespace_ has a trailing underscore. What do you think about changing that (and updating the documentation to match)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True. See 42bb43b.

Copy link
Contributor Author

@hidmic hidmic Jul 7, 2020

Choose a reason for hiding this comment

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

Spoke too soon, 2442051.

Even though it's an argument name and it is within an external C linkage block, the compiler barfs at namespace.

Copy link
Member

Choose a reason for hiding this comment

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

In rcl we are using node_namespace to avoid that problem, which looks a bit nicer that the trailing underscore.
That change sounds a bit unrelated to the PR though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's slightly redundant though.

Comment on lines 175 to 178
* \pre All publishers, subscribers, services, and clients created from this node must
* have been destroyed upon call. Some rmw implementations may choose to verify this,
* returning `RMW_RET_ERROR` and setting a human readable error message if any entity
* created from this node has not yet been destroyed.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* \pre All publishers, subscribers, services, and clients created from this node must
* have been destroyed upon call. Some rmw implementations may choose to verify this,
* returning `RMW_RET_ERROR` and setting a human readable error message if any entity
* created from this node has not yet been destroyed.
* \pre All publishers, subscribers, services, and clients created from this node must
* have been destroyed prior to this call. Some rmw implementations may verify this,
* returning `RMW_RET_ERROR` and setting a human readable error message if any entity
* created from this node has not yet been destroyed. However, this is not guaranteed and so
* callers should ensure that this is the case before calling this function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See 42bb43b.

Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

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

Looking good to me, thanks for the updates.

@@ -166,10 +156,9 @@ rmw_get_serialization_format(void);
* \param[in] name the node name
* \param[in] namespace_ the node namespace
Copy link
Member

Choose a reason for hiding this comment

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

In rcl we are using node_namespace to avoid that problem, which looks a bit nicer that the trailing underscore.
That change sounds a bit unrelated to the PR though.

@hidmic
Copy link
Contributor Author

hidmic commented Jul 7, 2020

One thing I changed in RMW implementations but didn't reflect here yet. Should we specify how memory is to be allocated?

rmw_context_t comes with an rcutils_allocator_t in options (which I went along with it naturally in some places). But there's also rmw_allocate() and friends, and C++ new / delete operators. I don't mind rolling back some changes, but I think having three different allocators that can be used interchangeably is a mess. CC @wjwwood .

@clalancette
Copy link
Contributor

rmw_context_t comes with an rcutils_allocator_t in options (which I went along with it naturally in some places). But there's also rmw_allocate() and friends, and C++ new / delete operators. I don't mind rolling back some changes, but I think having three different allocators that can be used interchangeably is a mess. CC @wjwwood .

I agree that this is kind of messy. But it seems orthogonal to this PR; should we go ahead and merge this one, and open an issue for further discussion of this topic?

@hidmic
Copy link
Contributor Author

hidmic commented Jul 13, 2020

But it seems orthogonal to this PR; should we go ahead and merge this one, and open an issue for further discussion of this topic?

Yeah, I guess. I do think that the way memory is allocated should be consistent and documented though.

@wjwwood
Copy link
Member

wjwwood commented Jul 13, 2020

I would agree with merge then fix in a follow up, just because there's so much inconsistency already.

I think the "right way" to do this is to always use the passed rcutils allocator, or pass one if there's not one being passed atm. We should deprecate the rmw_* allocator functions, and we should convert the rcutils allocator into a C++ allocator if we must use new/delete, otherwise placement new can be used in combination with the rcutils allocator.

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
Copy link
Contributor Author

hidmic commented Jul 14, 2020

Rebased to reflect #248 API changes.

@hidmic
Copy link
Contributor Author

hidmic commented Jul 14, 2020

Running CI up to test_rmw_implementation and all RMW implementations:

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

Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

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

One really minor nit; I'll approve, you can choose whether to accept it or not.

* created from this node has not yet been destroyed.
* This function will return early if a logical error, such as `RMW_RET_INVALID_ARGUMENT`
* or `RMW_RET_INCORRECT_RMW_IMPLEMENTATION`, ensues, leaving the given node handle unchanged.
* Otherwise, it will proceed despite errors, freeing as much resources as it can, including
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Otherwise, it will proceed despite errors, freeing as much resources as it can, including
* Otherwise, it will proceed despite errors, freeing as many resources as it can, including

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done in 79648b3.

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
@hidmic
Copy link
Contributor Author

hidmic commented Jul 15, 2020

Alright, all green. Merging.

@hidmic hidmic merged commit 63b5c6d into master Jul 15, 2020
@delete-merged-branch delete-merged-branch bot deleted the hidmic/update-node-docs branch July 15, 2020 13:22
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
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants