[Mpi-22] Another MPI-2.2 attribute ambiguity?

[Hubert Ritzdorf]

Hi,

NEC MPI uses #1 approach (such as for mpi_register_datarep and 
mpi_grequest_start).
I assume that #2 is more in the Fortran spirit.

Hubert

Jeff Squyres wrote:
> This is related to -- but different from -- MPI 2.2 ticket #55 
> ("MPI-2.1 Cross-language attribute example is wrong").  Explicitly 
> adding all the #55 CC members to this mail, plus a few others.
>
> I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific 
> behavior regarding the EXTRA_STATE arguments passed to the Fortran 
> keyval copy and delete functions (both the ADDRESS_KIND and deprecated 
> flavors).  I see two choices:
>
> 1. pass the user's original EXTRA_STATE argument by reference to the 
> callbacks, or
> 2. copy the user's original EXTRA_STATE into internal MPI storage and 
> pass *that* value by reference to the callbacks
>
> ==> Open MPI currently does #1.  What do other implementations do?
>
> I raise this issue because the text does not indicate which way is 
> right.  And I just ran across an old Sun test that assumed #2.  But 
> our internal copy of the Intel MPI tests assume #1 (to be fair: I have 
> no idea if the Intel tests originally assumed #2 and we changed them 
> to #1 over time).  Indeed, #2 is actually in-line with the philosophy 
> of storing attribute values in internal MPI storage.  E.g.:
>
>   INTEGER foo = 4
>   INTEGER bar
>   CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr)
>   foo = 5
>   CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr)
>
> bar should equal 4, not 5 (right?).
>
> So what does that mean (or imply) about the EXTRA_STATE value passed 
> to the Fortran callbacks?
>
> --Jeff Squyres
> Cisco Systems
>




* 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20090416/0e6595bc/attachment.bin>