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. :-)
Comments?
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.
-Paul
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
MPI_GROUP_EMPTY.
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
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
