In the data-type section there is an advice to implementors that
state that a copy can simply increase the reference count if
applicable. So, we might want to apply the same logic here ...
george.
On Jul 30, 2007, at 4:16 PM, Jeff Squyres wrote:
On Jul 30, 2007, at 9:58 AM, Lisandro Dalcin wrote:
In the mean time, I would prefer to follow the standard as close as
possible. If not, some external, stupid test suite (like the one I
have for mip4py) would report that OMPI is wrong about this point.
What exactly are you testing for?
Equality with the '==' C operator (i.e. handle equality). Using
Group.Compare() yields IDENT, as expected. But for groups, I
understand IDENT means either equal handles (in the C/C++ '==' sense)
or groups with the same size and rank order.
Upon reading Brian's answer and refreshing my cache by re-reading the
groups section of MPI-1, I have to agree with both of you. The
wording of the standard says that we should return a copy of a
group. But since groups are immutable, there really is no effective
difference as compared to simply returning the same group.
To be *really* strict in interpreting the results, you have to call
into question what "copy" means. One valid interpretation could be:
increment a reference count on an existing group and then return a
handle to that existing group (which is what OMPI does). So we
"copied" it -- in a lazy copy-on-write manner (just like fork() does
with memory pages between parents and children -- how's that for
precedent?). But since the group never changes, we never actually
bother to copy it. It's a [scalability] feature! :-)
So I think that using the C equality operator to compare the handles
that return will give you an answer that doesn't really mean
anything. Regardless of whether you get the "same" group back or
whether you get a "copy" back, you'll get MPI_IDENT if you compare
the original group with the one returned, and that's the result that
matters.
My $0.02...
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
