ivanpauno
commented
4 years ago I think that the graph guard condition should be triggered in all graph changes. A summary of graph changes:
- Anything that can change the output of the functions here.
- subscription and publisher matching count: this and this.
About non-dds rmw implementations, FastRTPS didn't use to have wait sets (now FastDDS have). They implemented rmw wait sets with the use of cv and listeners, so I think every non-DDS rmw implementation should be able to do that.
We could also have more fine grained guard conditions in the future.
About the difference between events and the graph guard condition, I think that in the future we could have a single event/condition type that can be added to the wait set instead of the wait set being able to wait in different kinds of objects.
hidmic
Feature request
Feature description
Currently, the API does not provide (or documents) a generic mechanism to wait for publishers (subscriptions) to match subscriptions (publishers) -- only the current match count is available for query. Thus, code that monitors these counts has to sleep and retry. That's inefficient and potentially brittle. It'd be nice to enable such waits.
Implementation considerations
It seems to me that a new pub/sub event would be the simplest solution. All Tier 1 RMW implementations have a form of pub/sub matching listener that can be leveraged:
rmw_fastrtps_cppandrmw_fastrtps_dynamic_cppalready use it (see here and here).rmw_connext_cppalready uses it (see here and here).rmw_cyclonedds_cppdoesn't use it yet (see here).It's worth noting that some
rcltests appear to rely on pub/sub matching triggering the graph guard condition. Regardless of that not being true for any of the current Tier 1 RMW implementations, it seems to me that would create too many unwarranted awakes. Also, pub/sub matching does not imply a graph change.