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

Dynamic Subscription (BONUS: Allocators): rosidl_dynamic_typesupport #2

Merged
merged 4 commits into from
Apr 11, 2023

Conversation

methylDragon
Copy link
Collaborator

Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

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

A few comments, otherwise lgtm

@methylDragon methylDragon force-pushed the runtime_interface_reflection_allocators branch from f338b56 to 8c78215 Compare April 10, 2023 04:22
Signed-off-by: methylDragon <methylDragon@gmail.com>
@methylDragon methylDragon force-pushed the runtime_interface_reflection_allocators branch from 8c78215 to 7c19712 Compare April 10, 2023 05:36
Signed-off-by: methylDragon <methylDragon@gmail.com>
@methylDragon methylDragon force-pushed the runtime_interface_reflection_allocators branch from 7c19712 to 7d0d91b Compare April 10, 2023 05:39
Signed-off-by: methylDragon <methylDragon@gmail.com>
Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

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

lgtm, I started reviewing this last night and finished it this morning. Though there are a lot of lines changed, they are just repeating for the most part.

Comment on lines 158 to +168
ROSIDL_DYNAMIC_TYPESUPPORT_PUBLIC
rcutils_ret_t
rosidl_dynamic_typesupport_dynamic_data_clone(
const rosidl_dynamic_typesupport_dynamic_data_t * other_dynamic_data,
rosidl_dynamic_typesupport_dynamic_data_t ** dynamic_data); // OUT
rcutils_allocator_t * allocator,
rosidl_dynamic_typesupport_dynamic_data_t * dynamic_data); // OUT

ROSIDL_DYNAMIC_TYPESUPPORT_PUBLIC
rcutils_ret_t
rosidl_dynamic_typesupport_dynamic_data_fini(
rosidl_dynamic_typesupport_dynamic_data_t * dynamic_data);
Copy link
Member

Choose a reason for hiding this comment

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

For other reviewers, the vast majority of changes for this pr can be summed up with this diff, basically adding allocators where we do allocation and avoiding double pointers as out parameters (matching how most of the rcl-like interfaces work, and the rest is mostly mechanical changes related to this shift.

struct rosidl_dynamic_typesupport_dynamic_data_s
{
rcutils_allocator_t allocator;
rosidl_dynamic_typesupport_dynamic_data_impl_t impl;

Choose a reason for hiding this comment

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

Not using hidden-type pimpl?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was thinking of doing that, but I thought it would be better to enforce that the impl is a complete type (and then defer it to the handle), so that we can enforce that the impl type has an allocator

Copy link
Contributor

Choose a reason for hiding this comment

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

But isn't the the type defined just above? That is, this implementation is completely in control of that structure, and thus can guarantee that it always has an allocator, no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ah, right.. I think I'm avoiding the use of a pointer so we don't have to keep doing null checks on the impl member as well..

The impl is unusable without the associated serialization support in either case, so in my view composition makes sense

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, actually, I largely agree with you. The only problem here is that if we want to add, remove, or change structure members in the implementation, we won't be able to backport it due to ABI concerns. But if we are OK with that limitation for now, we can leave it as-is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The implementation contains a void * handle, so that's a good escape hatch I think?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, it's good enough for now. It isn't our usual style, but it will do in a pinch.

{
RCUTILS_CHECK_ARGUMENT_FOR_NULL(dynamic_data, RCUTILS_RET_INVALID_ARGUMENT);
RCUTILS_CHECK_ARGUMENT_FOR_NULL(allocator, RCUTILS_RET_INVALID_ARGUMENT);

Choose a reason for hiding this comment

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

I think you need to check rcutils_allocator_is_valid(allocator) as part of argument checking (for all) - allocator could be non-null but contain null function pointers.

Copy link
Collaborator Author

@methylDragon methylDragon Apr 10, 2023

Choose a reason for hiding this comment

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

I might defer this so we don't invalidate the windows debug CI run :x

(I fixed it)

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.

The general idea seems OK to me, but I think we are missing a PR here (or I'm misunderstanding something).

src/api/dynamic_data.c Show resolved Hide resolved
Signed-off-by: methylDragon <methylDragon@gmail.com>
struct rosidl_dynamic_typesupport_dynamic_data_s
{
rcutils_allocator_t allocator;
rosidl_dynamic_typesupport_dynamic_data_impl_t impl;
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, it's good enough for now. It isn't our usual style, but it will do in a pinch.

@methylDragon methylDragon merged commit 8861cdc into rolling Apr 11, 2023
@delete-merged-branch delete-merged-branch bot deleted the runtime_interface_reflection_allocators branch April 11, 2023 06:02
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