test multiple rmw implementations for talker/listener test about rclpy HOT 12 CLOSED

@wjwwood I could take that off your plate if you want to

from rclpy.

Sure, it will be a few days until I get to it.

from rclpy.

Consider rewriting these tests using independent files for the listener side to fix flaky/failing tests on buildfarm.

Is rclpy.shutdown() supposed to allow one to change the rmw_implementation or does that have to happen in a different process?

import rclpy
from rclpy.impl.rmw_implementation_tools import get_rmw_implementations
from rclpy.impl.rmw_implementation_tools import select_rmw_implementation
select_rmw_implementation('rmw_opensplice_cpp')
rclpy.init()
#do stuff
rclpy.shutdown()
select_rmw_implementation('rmw_connext_cpp')

throws:

raise ImplementationAlreadyImportedException()

Is that the expected behaviour ?

from rclpy.

I don't think it is currently possible. But this is an important use case often requested in ROS 1 which I think is important to support. The user should be able to init, run stuff and shutdown and then be able to start over again within the same process.

from rclpy.

this is a workaround, and I'm actually not sure if it would work, but: are global variables provided by modules cleaned up after an import goes out of scope?

for example, would this reset the rmw implementation singleton?

def test(rmw_implementation_name):
    import rclpy
    from rclpy.impl.rmw_implementation_tools import get_rmw_implementations
    from rclpy.impl.rmw_implementation_tools import select_rmw_implementation
    select_rmw_implementation(rmw_implementation_name)
    rclpy.init()
    #do stuff
    rclpy.shutdown()

The longterm solution would be to add code to shutdown to set global implementation-related state back to None (https://github.com/ros2/rclpy/blob/master/rclpy/rclpy/impl/rmw_implementation_tools.py#L25-L27).

from rclpy.

I don't think it is currently possible. But this is an important use case often requested in ROS 1 which I think is important to support. The user should be able to init, run stuff and shutdown and then be able to start over again within the same process.

That is possible.

Being able to do:

• init
• shutdown
• init

Is different from:

• init
• shutdown
• change implementation
• init

The former should be possible in rclpy as-is. I don't think supporting the latter is extremely important though it would be nice if it worked. I do not believe it will though because I don't know how importing two Python extensions with the same symbols will work. If you would post the traceback, you'd see the error comes up when you try to change implementations after doing init, which is the issue here, not doing an init/shutdown/init cycle.

from rclpy.

I don't think that the singleton gets reset on shutdown whether it's used
inside a function or globally.

Now that it's confirmed that this is a wanted feature, your solution seems
very suitable.
Thanks!

On Mon, May 9, 2016 at 11:03 AM, Jackie Kay [email protected]
wrote:

this is a workaround, and I'm actually not sure if it would work, but: are
global variables provided by modules cleaned up after an import goes out of
scope?

for example, would this reset the rmw implementation singleton?

def test(rmw_implementation_name):
import rclpy
from rclpy.impl.rmw_implementation_tools import get_rmw_implementations
from rclpy.impl.rmw_implementation_tools import select_rmw_implementation
select_rmw_implementation(rmw_implementation_name)
rclpy.init()
#do stuff
rclpy.shutdown()

The longterm solution would be to add code to shutdown to set global
implementation-related state back to None (
https://github.com/ros2/rclpy/blob/master/rclpy/rclpy/impl/rmw_implementation_tools.py#L25-L27
).

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#22 (comment)

from rclpy.

Yes indeed doing init -> shutdown -> init works with the current implementation. So we can currently shutdown and start again in the same process as long as you don't want to change implementation in between.

I don't see many use cases where people would want to change implementation like this. It's actually only useful for testing multiple rmw_implementations on our end. That's why I was wondering if I should just modify the tests to do this in separate processes or modify rclpy to make it possible.

from rclpy.

I don't think we need a test for it if it's not a feature we are going to support.

from rclpy.

Sounds good to me.

from rclpy.

There are tests that test multiple implementations already by using the multiprocessing module. So you might look at those of you want to do it that way. But personally I think just having separate invocations of Python for each would be cleaner.

from rclpy.

Yes I think that separating them is cleaner too. Thanks for the feedback

from rclpy.