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 Thu, Nov 01, 2012 at 04:07:32PM -0400, George Bosilca wrote:
> Here is a quick question regarding the topi framework.
> - The mca_topo_base_output is opened unconditionally in topo_base_open.c:62
> - with your patch, mca_topo_base_output is closed conditionally in topo_base_close.c:46, but only in case mca_topo_base_components_opened_valid and mca_topo_base_components_available_valid are NULL. However, mca_topo_base_output is set to -1 in all cases right after.
> Why is that so?
mca_base_components_close closes the output if the third argument is NULL. So in this case calling opal_output_close after mca_base_components_close will result in a second call to opal_output_close.
> In fact I think the mca_topo_base_close is entirely wrong. It should close all mca_topo_base_components_opened_valid component, then all mca_topo_base_components_available_valid components and then close the mca_topo_base_output and set it to -1.
I looked into this as well. The select function for topo OBJ_DESTRUCTs mca_topo_base_components_opened and sets mca_topo_base_components_opened_valid to false. So if mca_topo_base_components_opened_valid is false it isn't safe to call mca_base_components_close. It is a little confusing and I don't know why the author if topo decided to do it that way.