[mpi-21] Ballot 4 proposal: INOUT arguments

[Rolf Rabenseifner]

Jeff, to your statement:

>If we also want to specify the behavior of the object, then a) that's  
>a huge change (and not one that I'm convinced we need), and b) we need  
>to add a second IN/OUT/INOUT to every language-neutral binding  
>representing what happens to the object.  Adding it to only a few of  
>the bindings doesn't seem consistent to me.

The trick is, that we have this problem only with the 
handle/object arguments.
In most cases we have 
- IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or
- OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq), or
- INOUT/INOUT which is abbreviated with INOUT, 
  e.g. in MPI_Type_commit(INOUT datatype)

The change, I'm proposing is based on your wish to see the IN for
the handles that are kept constant. 
Changing no words would continue to show the INOUT
for the objects itself (that's the way MPI-2 was written).

I would not say, that it is a huge change to add the handle IN
information to all the interfaces.
It is not huge, although there are more routines affected 
(also many MPI_FILE routines) as you have mentioned in your
first mails.

Okay?

Best regards
Rolf

On Thu, 31 Jan 2008 09:56:48 -0500
 Jeff Squyres <jsquyres_at_[hidden]> wrote:
>On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote:
>
>>> 1. Why do we need to indicate the INOUT status of the back-end MPI
>>> object in the language neutral bindings?  All the bindings --
>>> regardless of language -- only deal with the MPI handles, not the  
>>> back-
>>> end MPI objects.
>>>
>>> 2. Adding qualifiers on what is supposed to happen to the back-end  
>>> MPI
>>> object would seem to require additional semantics on the back-end MPI
>>> object.  Should we really be specifying what the implementation must/
>>> must not do with the back-end MPI object?  Who benefits from that?
>>
>> After all the MPI_BOTTOM discussion and not knowing what future
>> languages will bring, I didn't want to remove existing information
>> from the standard. An opaque object in MPI consists always
>> of two things: the handle and the object itself.
>>
>> The language independent interface should reflect this.
>>
>> I thought that especially for the const discussion it would be good
>> to see the IN for the handle.
>
>I agree.
>
>> For future HPCS languages, it may be
>> also necessary see the INOUT for the object itself.
>
>I guess my point is that the language bindings don't specify anything  
>about the object itself anywhere else.
>
>If we also want to specify the behavior of the object, then a) that's  
>a huge change (and not one that I'm convinced we need), and b) we need  
>to add a second IN/OUT/INOUT to every language-neutral binding  
>representing what happens to the object.  Adding it to only a few of  
>the bindings doesn't seem consistent to me.
>
>-- 
>Jeff Squyres
>Cisco Systems
>
>_______________________________________________
>mpi-21 mailing list
>mpi-21_at_[hidden]
>http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)