Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-07-18 15:42:00

I don't recommend our solution as a general approach - we moved the object instance to the framework base so it never goes out of memory.

Regardless, it seems to me that proper cleanup is the better solution, although it means work. I've asked that it be added to next week's telecon agenda so we can reach some resolution.

On Jul 18, 2014, at 9:35 AM, Gilles Gouaillardet <gilles.gouaillardet_at_[hidden]> wrote:

> It would make sense, though I guess I always thought that was part of what happened in OBJ_CLASS_INSTANCE - guess I was wrong. My thinking was that DEREGISTER would be the counter to INSTANCE, and I do want to keep this from getting even more clunky - so maybe renaming INSTANCE to be REGISTER and completing the initialization inside it would be the way to go. Or renaming DEREGISTER to something more obviously the counter to INSTANCE?
> just so we are clear :
> on one hand OBJ_CLASS_INSTANCE is a macro that must be invoked "outside" of a function :
> It *statically* initializes a struct.
> on the other hand, OBJ_CLASS_DEREGISTER is a macro that must be invoked inside a function.
> using OBJ_CLASS_REGISTER is not only about renaming, it also requires to move all these invokations into functions.
> my idea of having both OBJ_CLASS_INSTANCE and OBJ_CLASS_REGISTER is :
> - we do not need to move OBJ_CLASS_INSTANCE into functions
> - we can have two behaviours depending on OPAL_ENABLE_DEBUG :
> OBJ_CLASS_REGISTER would simply do nothing if OPAL_ENABLE_DEBUG is zero (and opal_class_initialize would still be invoked in opal_obj_new). that could also be a bit faster than having only one OBJ_CLASS_REGISTER macro in optimized mode.
> that being said, i am also fine with simplifying this, remove OBJ_CLASS_INSTANCE and use OBJ_CLASS_REGISTER and OBJ_CLASS_DEREGISTER
> about the bug you hit, did you already solve it and how ?
> a trivial workaround is not to dlclose the dynamic library (ok, that's cheating ...)
> a simple workaround (if it is even doable) is to declare the class "somewhere else" so the (library containing the) class struct is not dlclose'd before it is invoked (ok, that's ugly ...).
> what i wrote earlier was misleading :
> foo = OBJ_NEW(class);
> then
> opal_class_t class_class = {...};
> foo->super.obj_class = &class_class;
> class_class is no more accessible when the OBJ_RELEASE is called since the library was dlclose'd, so you do not even get a change to invoke the destructor ...
> a possible workaround could be to malloc a copy of class_class, have foo->super.obj_class point to it after each OBJ_NEW, and finally have its cls_destruct_array point to NULL when closing the framework/component.
> (of course that causes a leak ...)
> Cheers,
> Gilles
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription:
> Link to this post: