Archived

This forum has been archived. Please start a new discussion on GitHub.

Properly shutting ICE down.

I have embedded ICE in a MATLAB Simulink S-Function, and seem to be having trouble shutting it down properly. What must be done to shutdown/destroy an ICE implimentation. Current I destory the object that holds the pointers for the proxy ObjectPtx and the Prx and Ptr for a publisher and a subscribe for IceStorm, and call shutdown and destory on my Ice::CommunicatorPtr, and destory it's containing object. I still get:
warning: The communicator is not the last Ice object that is
deleted. (You can disable this warning by setting the
property `Ice.Warn.Leaks' to 0.)

What else should be done?

Another question, say I have an IceStorm interface that may or may not be bound to a proxy/adapter/topic. How do I check if it is instantiated, and if it has been how do I switch topics "cleanly"?

Another question, do I need a proxy for each subscriber? What if I have two different interfaces, can they be on the same proxy? Same adapter? Do Ice::ObjectAdapterPtr and IceStorm::TopicPrx objects need to stay around for the subscribers to function?

Comments

  • matthew
    matthew NL, Canada
    As a general point from reading your questions I think you are a little confused about what a proxy really represents. I suggest you read the Ice object model section of the Ice manual to clarify this.
    I have embedded ICE in a MATLAB Simulink S-Function, and seem to be having trouble shutting it down properly. What must be done to shutdown/destroy an ICE implimentation. Current I destory the object that holds the pointers for the proxy ObjectPtx and the Prx and Ptr for a publisher and a subscribe for IceStorm, and call shutdown and destory on my Ice::CommunicatorPtr, and destory it's containing object. I still get:
    ...

    You shouldn't have to anything very magic to cleanly shutdown other than shutdown and destroy the communicator. Most likely the warning is due to a global variable holding an proxy, or some sort of circular reference count (A holds a B and B holds A).
    Another question, say I have an IceStorm interface that may or may not be bound to a proxy/adapter/topic. How do I check if it is instantiated, and if it has been how do I switch topics "cleanly"?

    What do you mean by an IceStorm interface?
    Another question, do I need a proxy for each subscriber?



    You mean for each subscribe call on the same topic? Or on different topics? If you subscribe twice on the same topic with the same proxy then you'll get duplicate event deliveries (which is likely not what you want). If you subscribe on two different topics with the same subscriber proxy then that will work no problem.
    What if I have two different interfaces, can they be on the same proxy?


    Yes, as long as the servant to which the proxy refers implements the appropriate interfaces then this will work.
    Same adapter? Do Ice::ObjectAdapterPtr and IceStorm::TopicPrx objects need to stay around for the subscribers to function?

    The object adapter will continue to exist until deactivated which will happen at communicator shutdown or when you manually deactivate it. The TopicPrx is not necessary to keep around.
  • matthew wrote:
    Most likely the warning is due to a global variable holding an proxy
    I put the Ice::ObjectPrx in a struct, and destroy the struct before calling the communicator shutdown/destroy, I don't think so.
    matthew wrote:
    circular reference count (A holds a B and B holds A)
    What would be an example of this, because I don't think I quite understand what you mean.
    matthew wrote:
    What do you mean by an IceStorm interface?

    <InterfaceName>Prx, like MonitorPrx. I have it as global, but it won't get initilized until the
    monitorOut = XPlane::ReturnInterfacePrx::uncheckedCast(pub);
    
    line. How do I check for that, and if it has been initilized how to shut it down.
    The object adapter will continue to exist until deactivated which will happen at communicator shutdown or when you manually deactivate it. The TopicPrx is not necessary to keep around.

    Even if the Ice::ObjectAdapterPtr goes out of scope? Ok.
    If you subscribe on two different topics with the same subscriber proxy then that will work no problem.

    What would the code look like? This line is the one the confuses me
    proxy = adapter->addWithUUID(monitorIn);
    
    Does this not bind monitorIn to the proxy? Can I have different MonitorPrt's(monitorIn's type) too different topics, on the same proxy?
  • matthew
    matthew NL, Canada
    litghost wrote:
    I put the Ice::ObjectPrx in a struct, and destroy the struct before calling the communicator shutdown/destroy, I don't think so.

    What do you mean "destroy the struct"?
    What would be an example of this, because I don't think I quite understand what you mean.
    class FooI : public Foo
    {
    public:
    //...
    BarPtr bar;
    };
    typedef IceUtil::Shared<FooI> FooIPtr;
    
    class BarI : public Bar
    {
    public:
    //...
    FooPtr foo;
    };
    typedef IceUtil::Shared<BarI> BarIPtr;
    
    FooIPtr foo = new FooI();
    BarIPtr bar = new BarI();
    foo->bar = bar;
    bar->foo = foo;
    
    <InterfaceName>Prx, like MonitorPrx. I have it as global, but it won't get initilized until the
    monitorOut = XPlane::ReturnInterfacePrx::uncheckedCast(pub);
    
    line. How do I check for that, and if it has been initilized how to shut it down.

    Perhaps this global is the cause of your leak?

    If you want to see whether the proxy has been assigned yet then you can simply do:
    if(monitorOut)
    {
      // Initialized
    }
    

    What do you mean by shut it down?
    Even if the Ice::ObjectAdapterPtr goes out of scope? Ok.

    Everything is reference counted in Ice, so yes. Nothing goes away if you are using it :)
    What would the code look like? This line is the one the confuses me
    proxy = adapter->addWithUUID(monitorIn);
    
    Does this not bind monitorIn to the proxy? Can I have different MonitorPrt's(monitorIn's type) too different topics, on the same proxy?

    I don't know what you mean by "bind". There is no explicit association of the proxy with the servant if that's what you mean. The lifecycle of the proxy has nothing to do with the lifecycle of the Ice object at all.

    A proxy refers to an Ice object which is identified by the objects identity. In the case of the Ice object that you've given above the identity is a UUID. UUIDs are generated randomly and is guaranteed to be unique.

    Given that a proxy refers to exactly one Ice object, the answer to your second question is no. Each proxy refers to one instance of an Ice object, not multiple.
  • matthew wrote:
    What do you mean "destroy the struct"?
    For MATLAB memory management if you want to be reentrant you can have no globals, but you can have work vectors, pointers that MATLAB stores that you can recall after a function has gone out of scope. I have two structures in work vectors right now, one is a collection of a Prx, a Prt and my proxy instance, the other contains the Ice::CommunicatorPtr. During shutdown I delete the collection structure, call shutdown and destroy, and then delete the structure containing the Ice::CommunicatorPtr.
    class FooI : public Foo
    {
    public:
    //...
    BarPtr bar;
    };
    typedef IceUtil::Shared<FooI> FooIPtr;
    
    class BarI : public Bar
    {
    public:
    //...
    FooPtr foo;
    };
    typedef IceUtil::Shared<BarI> BarIPtr;
    
    FooIPtr foo = new FooI();
    BarIPtr bar = new BarI();
    foo->bar = bar;
    bar->foo = foo;
    

    Defiantly don't have something like that.
    Perhaps this global is the cause of your leak?

    Different side of the implimentation. Not the same as the one reporting the leak.
    What do you mean by shut it down?
    I want to change the topic it is subscribed too. Also there are times I want it to simply be unsubscribed until further notice.
    Given that a proxy refers to exactly one Ice object, the answer to your second question is no. Each proxy refers to one instance of an Ice object, not multiple.
    So ultimately, if I want to have multiple Ice objects I need multiple proxies (this was my initial question, believe it or not).
    Everything is reference counted in Ice, so yes. Nothing goes away if you are using it :)

    How do you stop using everything that came from a communicator? shutdown() command?
  • matthew
    matthew NL, Canada
    litghost wrote:
    So ultimately, if I want to have multiple Ice objects I need multiple proxies (this was my initial question, believe it or not).

    Yes. A proxy refers to one Ice object. A proxy contains the identity of the Ice object to which it refers. Its a bit like an immutable pointer.
    How do you stop using everything that came from a communicator? shutdown() command?

    shutdown() and destroy().

    Most likely what is occurring is that you are holding proxy references when you destroy the communicator. If you do this you will get the problem you reported. The solution is to release the proxy references first.
  • matthew wrote:
    Most likely what is occurring is that you are holding proxy references when you destroy the communicator. If you do this you will get the problem you reported. The solution is to release the proxy references first.

    Note that this is not an error. It is only a warning, about Ice not being able to check for certain memory leaks. Ice can only do this check if the communicator is the last object which is destroyed. If you have any globals, then this is usually not the case. However, this doesn't mean that there actually are any memory leaks in your code--it just means that the Ice runtime cannot perform certain leak checks.
  • matthew wrote:
    The solution is to release the proxy references first.

    And how do you do that?
  • matthew
    matthew NL, Canada
    Assign them to zero.
    HelloPrx h = // some proxy;
    // use h
    h = 0;
    
  • Ice available for ML/SL?

    Hi,

    I have read this thread and it seems to be quite interesting using Ice for ML/SL. I would like to use it as well, but could not find any material for this. Can anybody help me here?

    Thank you for your support!!

    Regards,
    Christian