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 ...
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
> My $0.02...
> Jeff Squyres
> Cisco Systems
> devel mailing list