Jeff Squyres wrote:
> 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. :-)
Note, CT6 (Sun's previous implemention) also passed these tests. Sun
would like this test passing
to be maintained until some concrete message is made by the forum. That
being said I would agree
with Jeff's proposal of backing out the change and putting in comments 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! :-(
>> 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