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.
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