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. :-)
To paraphrase mothers everywhere "If the other MPI implementations all
jumped off a bridge, would you?"
For better, or for worse, this sounds like a case of the Intel tests
providing the clarification that is missing in the specification. IMHO,
the right final solution is to implement whatever the reconvened MPI
Forum decides on this issue. The most sensible solution in the meantime
is to apply the principle of least surprise - which appears to be "do
what the Intel tests expect".
So, I guess I would agree with Jeff that the changes should be backed
out, but good comments left in their place.
> 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
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900