This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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 ;)
> -Nathan Hjelm
> HPC-3, LANL
> devel mailing list