Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

This is ticketed at https://code.ros.org/trac/ros/ticket/3403. There I wrote:

I've noticed this issue with unsubscribe callbacks too. However, it's not true that they're never called; they do get called exactly 60s after you subscribe.

In practice this shouldn't normally be an issue. In each nodelet we use connect callbacks to control whether it hooks into a data source (camera or ROS topic). As long as it's getting data, it publishes some processed output. So if all subscribers to the output unsubscribe, the next call to publish() triggers the disconnect callback, which unhooks from the data source. So as long as you're streaming data, disconnects will be timely.

It's still annoying and can cause odd behavior in practice - e.g. if the register nodelet doesn't get the tf data it needs, it can't publish(), so it takes the full 60s to disconnect. So I'd like to see this fixed, or at least know why it happens.

Generally this hasn't been an issue for us - if we need the disconnect callback called immediately, it's because we're shutting down a publisher that's continuously spewing data. Do you have a use case where you require a timely disconnect callback for an inactive publisher?

This is ticketed at https://code.ros.org/trac/ros/ticket/3403. https://code.ros.org/trac/ros/ticket/3403. There I wrote:

I've noticed this issue with unsubscribe callbacks too. However, it's not true that they're never called; they do get called exactly 60s after you subscribe.

In practice this shouldn't normally be an issue. In each nodelet we use connect callbacks to control whether it hooks into a data source (camera or ROS topic). As long as it's getting data, it publishes some processed output. So if all subscribers to the output unsubscribe, the next call to publish() triggers the disconnect callback, which unhooks from the data source. So as long as you're streaming data, disconnects will be timely.

It's still annoying and can cause odd behavior in practice - e.g. if the register nodelet doesn't get the tf data it needs, it can't publish(), so it takes the full 60s to disconnect. So I'd like to see this fixed, or at least know why it happens.

Generally this hasn't been an issue for us - if we need the disconnect callback called immediately, it's because we're shutting down a publisher that's continuously spewing data. Do you have a use case where you require a timely disconnect callback for an inactive publisher?