Revision history [back]

I had a look in the rospy code. The problem is that the publisher in the subprocess does not have a QueuedConnection object added to its connections list. The connections are added in a separate thread which is spawned by the main process when the node is initialised.

Specifically, client.py::init_node line 337 starts the TCPROS server, calling tcpros_base::start which launches a thread to run the run function which accepts connections. Connections are then created on line 165, via the route inbound_handler->tcpros_base::_tcp_server_callback->self.topic_connection_handler->tcpros_pubsub::TCPROSHandler::topic_connection_handler->topics::add_connection->tcpros_pubsub::QueuedConnection . It seems that this does not modify the topic that exists in the subprocess, and so the publisher never gets any connections in the subprocess, whereas if it were in the main process things would be OK.

I had a look in the rospy code. The I think that the problem is that the publisher in the subprocess does not have a QueuedConnection object added to its connections list. The connections are added in a separate thread which is spawned by the main process when the node is initialised.

Specifically, client.py::init_node line 337 starts the TCPROS server, calling tcpros_base::start which launches a thread to run the run function which accepts connections. Connections are then created on line 165, via the route inbound_handler->tcpros_base::_tcp_server_callback->self.topic_connection_handler->tcpros_pubsub::TCPROSHandler::topic_connection_handler->topics::add_connection->tcpros_pubsub::QueuedConnection . It seems that this does not modify the topic that exists in the subprocess, and so the publisher never gets any connections in the subprocess, whereas if it were in the main process things would be OK.