Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] GROUP_EMPTY fixes break intel tests :-(
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-12-06 11:07:11

I should also note the following:

- LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is
returned to the user, and allows GROUP_EMPTY in GROUP_FREE)

- MPICH2 has the following comment in GROUP_FREE (and code to match):

            /* Cannot free the predefined groups, but allow GROUP_EMPTY
                because otherwise many tests fail */

So I'm thinking that we should allow GROUP_EMPTY in GROUP_FREE -- back
out Edgar's changed and put in some big comments about exactly why. :-)


On Dec 6, 2007, at 11:01 AM, Jeff Squyres wrote:

> So the changes that we debated and had Edgar put in *do* break some
> intel tests. Doh! :-(
> MPI_Group_compare_f
> MPI_Group_intersection2_c
> MPI_Group_intersection2_f
> It looks like these tests are specifically calling MPI_GROUP_FREE on
> I note that there is code in the ompi/group/group_*.c code that
> specifically calls OBJ_RETAIN on ompi_group_empty when we return
> MPI_GROUP_EMPTY. I wonder if this RETAIN was added (and the MPI param
> check removed) in reaction to the intel tests...?
> Can someone cite again where we thought the spec said that we should
> not free GROUP_EMPTY? Was is just on the argument that it's a
> predefined handle and therefore should never be freed?
> I cannot find any specific text in 1.2 or the errata stating that it's
> bad to free GROUP_EMPTY. I agree that this is somewhat counter to the
> rest of the MPI philosophy of not freeing predefined handles, though.
> --
> Jeff Squyres
> Cisco Systems
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
Cisco Systems