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?
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
--
Jeff Squyres
Cisco Systems
