Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Iox #415 Make
ServiceRegistry
aware of completeServiceDescription
#860Iox #415 Make
ServiceRegistry
aware of completeServiceDescription
#860Changes from all commits
a51eeff
88fea8f
02071d4
973b166
e20c118
5105289
ea0ed42
fb20956
b7c3f97
5e0f5b0
8e24029
486a008
d2c0aaf
cef63b5
2fec024
479ea0b
10b3658
fcb415a
4ffa025
7cc5ee8
6493ba5
cb08485
e2ed8c3
b7e7e9c
93d5a41
27271df
43a4f7f
f862b44
58dfb50
f8b3ff6
41b8294
bb8a348
78d5952
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that we now call
findService
, provide a service ID and what will be returned is a container with full CaProServiceDescription? The Service IDs in this Service Description would be some kind of redundant information as hopefully you only get CaPro IDs that match the requested service IDThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct. Service IDs in this case would all be "ServiceA". IMHO this is beneficial to the old design as the user will now be able to read all the other members of a
ServiceDescription
. This could in future be also e.g. QoS settings.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be precise: The return value is a vector wrapped in an expected
cxx::expected<ServiceContainer, FindServiceError>
andusing ServiceContainer = iox::cxx::vector<capro::ServiceDescription, MAX_NUMBER_OF_SERVICES>;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This API feels like the old C APIs and it is unnecessary to add the searchResult as a reference to find in here.
Please adjust it to
This can be used much easier, see
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be easier more natural to use like this, but consider the case where we can store 1000 services or more.
There is a reason to have an API like this with our memory constraints, and this is that the return type would always need to support maximum number of elements in the returned container. We have no truly dynamic containers and cannot easily (or at all) define those. It is possible that the user may define the return type as a template parameter, but this is also bad to use for return values (cannot be inferred, needs to be specified explicitly).
Therefore the more natural API would be less efficient memory wise. Runtime wise it would likely be ok, if the unused container elements are not actually initialized with anything (nor memory set to 0).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @MatthiasKillat in general I agree with you @elfenpiff a
auto result = registry.find("bla", "blubb", "fuu")
is much nicer. A typical ADAS or robotics system will for sure have something around 1000 services. We would not let all the services be findable, but let's assume a size of 200. That's a already a huge number and it will have some runtime effect as we would return lots ofcxx::string
's via copy here. I'd propose to do a measurement once all building blocks are in place for the new discovery API. This can easily be changed as it is no user-facing API.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do this later. There are all kinds of trade-off. Returning pointers vs. values, creating the container vs. letting the user pass it to be filled, defining the container type vs. leaving it generic as a template parameter etc.
One could even use a functional approach, letting the user pass a function which specifies what to do with the found service.
Hard to tell what is the best approach here, depends on what is the priority: generality, usability, efficiency...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the approach with the lambda. That's quite modern and gives the user maximum freedom
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this does not work out for whatever reason an unordered multimap based on hashing is also suitable here.
The yet to be disclosed implementation of the tree is fine though, the only problem is the worst case space and that is not easy to fix. We will see when we replace it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that with static memory space is a problem almost regardless of data structures, just for some it is more problematic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we had it as a type this would be a special case for the either monad. (Also cxx::expected is a special case as well, where the types have specific meaning).
The reason I state this is that I think that the variant has more overhead for tracking its actual type than actually needed in a purely binary choice between types. Just optimization of course, but the building block is worth thinking about some time.