-
Notifications
You must be signed in to change notification settings - Fork 682
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
Improve intraprocess communication behavior #649
Comments
I am not sure this is feasible. The publisher could use QoS settings to deliver previously published messages to late joining subscribers. In that case skipping the inter process publish just because no subscribers are present at the moment would be wrong. |
Obviously for non volatile durability you have to publish anyways, but yes it's worth noting that this only works if there are no subscriptions and durability is volatile. |
@mjcarroll did put down your offline discussion w/ @wjwwood in a document? Maybe I can start pushing one of these bullets. Which one's the smallest? :) |
Probably not ready for a PR, but includes more notes from our discussion: https://github.com/ros2/design/blob/mjcarroll/intraprocess/articles/160_intraprocess_communications.md |
Latest PR on this topic: ros2/rclcpp#690. |
Hi, I was having a look at the current intra process manager. If no, could I ask which are the reasons why it's required? |
That function is performing the intra process message passing functionality which is a |
@dirk-thomas From what I'm understanding, do_intra_process_publish, calls Could you explain me why you say that it's not involving the DDS? |
Well, it does publish a meta-message but it uses the RMW interface for this. So you could use a non-DDS RMW implementation. Can you clarify what you are asking for? If there are any plans to make the intra process communication without sending any meta-message through the RMW impl.? |
Yes, exactly. |
While that would be an option there are also downsides to that approach. When you switch from inter- to intra- your behavior might change if the intra- part doesn't implement the very exact behavior than the inter- in terms of queuing, QoS, etc. You find some information about the topic in the ROSCon 2015 slides (I couldn't find anything better). Currently there is no plan to change the implementation but there is always room for improvements. |
What @dirk-thomas said is right, basically sending the "envelope" message via rmw (DDS or whatever it may use) allows us to avoid a lot of work needed to emulate QoS features like deadline, lifespan, keep last vs keep all history, etc... Also, it prevents us from having to emulate scheduling (publish should be async, queuing the data but not calling the subscription directly). We could implement our own queuing to replace that, but it would be a good deal of work if we also wanted to have consistent behavior, which we do. That being said, we may still do that in the future, but for now this gives a significant improvement for large data, so it's an incremental improvement. There's also this idea of "direct dispatch" which is what ROS 1 did, where you have publish directly call subscription callbacks, one after another. The problem with this is that if you add a subscription callback that takes a long time, now your publish function will suddenly take substantially longer. As a default behavior we're trying to avoid things like that. However, some people may desire that behavior, so we think we'd like to try to provide that as an option in the future along side the default which keeps publish async. |
Since the three main tasks have been addressed, this issue can be closed. |
There have been some performance issues uncovered in the behavior and assumptions made in the implementation of intraprocess communications. This is a meta-ticket to track improvements to intraprocess communications planned for D-turtle.
Tasks:
rmw_count_matched_*
to avoid publishing interprocess when a publication only has intraprocess subscriptions.(stretch) offer "direct dispatch" (C++ only) - This would be similar to how ROS1 nodelets worked in that subscriptions could be directly invoked from the publication-sidepublish
method. This is particularly useful in processing pipeline environmentsBased on:
References:
The text was updated successfully, but these errors were encountered: