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.gouaillar...@gmail.com> 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 :
> OBJ_CLASS_INSTANCE(class);
> 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
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15198.php
