On Thu, Nov 01, 2012 at 07:22:42PM -0400, George Bosilca wrote:
> On Nov 1, 2012, at 19:07 , Nathan Hjelm <hjelmn_at_[hidden]> wrote:
> > I was going to address this second inconsistency with another patch but now seems like a good time to get a see if anyone has an opinion about how this should be fixed. I can think of two simple fixes:
> > 1) Since mca_base_components_open calls OBJ_CONSTRUCT should mca_base_components_close call OBJ_DESTRUCT?
> > 2) Should the caller be responsible for both the OBJ_CONSTRUCT and OBJ_DESTRUCT calls?
> I'm fine either way, but I do have a slight preference for 1.
> >> - it force us to have one specific output for each framework
> > This isn't the case at the moment since frameworks can call opal_output_close on any extra output streams. It would be better if frameworks have t close all open output streams using opal_output_close instead of using mca_base_components_close. If we want to change the semantics of mca_base_components_close I can redo this patch. Anyone have an opinion on this?
> mca_base_components_close should not close an output stream opened by another entity (or if it does the arguments should be changed to int* and it should set it to -1). I think that counts as having an opinion ;)
I agree and there seems to be no other opinions on this matter. So, attached is a new version of the change that modifies the behavior of mca_base_components_close to not close the output. I made the appropriate changes to each framework to reflect this change.
I will RFC another patch to further modify the behavior of mca_base_components_close to call OBJ_DESTRUCT on the available components iff the list is empty. This will be a big step towards valgrind safety.
New What: Modify the behavior of mca_base_components_close to not close the opal_output. Any component that calls opal_output_open MUST always call opal_output_close.
New When: Tomorrow (Nov 6) @ 12:00PM MST