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

Fastdds type support extensions #67

Merged
merged 6 commits into from
May 11, 2021

Conversation

MiguelCompany
Copy link
Collaborator

@MiguelCompany MiguelCompany commented Mar 17, 2021

This extends the initialization callback max_serialized_size so it returns whether the type support refers to a POD type.

This change is required in order to support zero-copy on rmw_fastrtps_cpp.

Connects to ros2/rmw_fastrtps#516
Connects to ros2/rmw_connextdds#14

// Start considering the type is plain.
// Internal methods will set values to false when necessary.
full_bounded = true;
is_plain = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

@MiguelCompany nit: consider moving this into max_serialized_size_*(). It's unusual for a function to not have a well defined output argument value.

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 understand your point. However, as the internal methods may be called from other internal methods (in the case of composed types), a parent may have turned one of the booleans to false.

Consider the following messages:

# Inner.msg
uint32 index
uin8[10] data

# Outer.msg
string title
Inner data

When calling _Outer__max_serialized_size, the following sequence of events will occur:

  • _Outer__max_serialized_size will set both booleans to true and call max_serialized_size_Outer
  • max_serialized_size_Outer will set both booleans to false due to the string title
  • max_serialized_size_Outer will call max_serialized_size_Inner due to the field data
  • max_serialized_size_Inner will not change the booleans

When calling _Inner__max_serialized_size, the following sequence of events will occur:

  • _Inner__max_serialized_size will set both booleans to true and call max_serialized_size_Inner
  • max_serialized_size_Inner will not change the booleans

In summary:

  • The public API on this package is the one defined for the callbacks.
  • For that API, this PR is fixing the code in order to always have a well-defined output argument value.
  • max_serialized_size_* should be considered internal, but needs to be exported in order for messages to be included on other messages

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, that's a problem only because max_serialized_size_*() functions for composed types are given the same is_plain to mutate. I won't block on this, maybe it's best for performance, but I will point out it obscures the logic a bit. A logical AND of the is_plain variable for each field in a type is easier to read.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok. Fixed in e69b64e

// Start considering the type is plain.
// Internal methods will set values to false when necessary.
full_bounded = true;
is_plain = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

@MiguelCompany same as above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

See above

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed in e69b64e

@MiguelCompany MiguelCompany requested a review from hidmic April 8, 2021 05:30
@MiguelCompany
Copy link
Collaborator Author

@hidmic I addressed your concerns

@clalancette May we run a CI on this?

@clalancette
Copy link
Contributor

CI:

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

@MiguelCompany
Copy link
Collaborator Author

@clalancette I think you forgot to include ros2/rmw_connextdds#14

@clalancette
Copy link
Contributor

CI:

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

@MiguelCompany
Copy link
Collaborator Author

@clalancette As stated in the description, this PR

Connects to ros2/rmw_fastrtps#516
Connects to ros2/rmw_connextdds#14

So both should be used on the build. Sorry for the confusion.

Thank you!

@MiguelCompany
Copy link
Collaborator Author

@clalancette Friendly ping

Signed-off-by: Miguel Company <MiguelCompany@eprosima.com>
Signed-off-by: Miguel Company <MiguelCompany@eprosima.com>
Signed-off-by: Miguel Company <MiguelCompany@eprosima.com>
Signed-off-by: Miguel Company <MiguelCompany@eprosima.com>
@MiguelCompany MiguelCompany force-pushed the fastdds-type-support-extensions branch from e69b64e to 81fdacd Compare April 15, 2021 05:45
Signed-off-by: Miguel Company <MiguelCompany@eprosima.com>
@MiguelCompany MiguelCompany force-pushed the fastdds-type-support-extensions branch from 81fdacd to 7e709c2 Compare April 15, 2021 07:45
@MiguelCompany
Copy link
Collaborator Author

@clalancette I rebased this and added commit 7e709c2, in which I make the change binary compatible.

@clalancette
Copy link
Contributor

Here's a CI with what should be all of the correct pieces in place:

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

Signed-off-by: Miguel Company <MiguelCompany@eprosima.com>
@MiguelCompany
Copy link
Collaborator Author

@clalancette I just fixed the linter errors on the generated code.

@clalancette
Copy link
Contributor

Here's another try:

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

@clalancette
Copy link
Contributor

clalancette commented Apr 22, 2021

CI again:

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

@MiguelCompany
Copy link
Collaborator Author

@clalancette eProsima/Fast-DDS#1931 fixes the assertions

@clalancette
Copy link
Contributor

Windows Debug again: Build Status

@MiguelCompany
Copy link
Collaborator Author

Windows Debug again: Build Status

@clalancette The has been stalled for three days before even starting to build.

15:38:00 C:\J\workspace\ci_windows>rem Kill any running docker containers, which may be leftover from aborted jobs 
15:38:00 
15:38:00 C:\J\workspace\ci_windows>powershell -Command "if ($(docker ps -q) -ne $null) { docker stop $(docker ps -q)}" 

@clalancette
Copy link
Contributor

Let's try again:
Windows Debug again: Build Status


#define ROSIDL_TYPESUPPORT_FASTRTPS_UNBOUNDED_TYPE 0x00
#define ROSIDL_TYPESUPPORT_FASTRTPS_BOUNDED_TYPE 0x01
#define ROSIDL_TYPESUPPORT_FASTRTPS_PLAIN_TYPE 0x03
Copy link
Contributor

Choose a reason for hiding this comment

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

@MiguelCompany meta: why not an enum? You'd get type checking.

@hidmic
Copy link
Contributor

hidmic commented May 5, 2021

@clalancette it looks like this PR's ready to go?

@clalancette
Copy link
Contributor

@clalancette it looks like this PR's ready to go?

Yeah, I think this is ready to go in with ros2/rmw_fastrtps#523 and ros2/rmw_connextdds#14 , but I'd like to run one more CI on it. But I'm going to hold off on that until we sort out ros2/rclcpp#1657

@clalancette
Copy link
Contributor

clalancette commented May 6, 2021

CI:

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

@clalancette
Copy link
Contributor

The warnings are all just an artifact of this needing to be rebased. The test failures look like known flakes. So I'm going to go ahead and merge this along with the rest of the PRs for this.

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.

4 participants