Subject: Re: Multifarious

From: [email-masked] (Tom Henderson)
Date: Tue, 5 Jan 93 10:36:12 MST

I have a few short comments on Jim's comments...  

> 
> Removing internal state
> =======================
> 
> I'd also like to remove the hidden state ("last message"), there are
> various ways of achieving this, none of which is exceptionally
> attractive.
> 
> 1) Return a structure from MPI_RECV (and friends)
>    This is fine in C, but not good in Fortran 77 (and may be more
>    expensive than we want when you don't need any of the information).
> 
>    e.g.
>    typedef struct MPI_REPLY
>    {
>       int status;
>       int nbytes;
>       int whoFrom;
>       int tag;
>       /* More ? */
>    } MPI_REPLY; 
> 
>    { 
>       MPI_REPLY res;
> 
>       res = MPI_RECV(...);
> 
>       if (res.whoFrom == 0) 
> 
>       ... etc ...
>    }
>    
> 
> 2) Return results indirect through individual parameters (arguments for the
>    Fortran inclined)
> 
>    This works, but is very error prone, particularly in Fortran when
>    the arguments are INOUT. (We have an interface like this at the
>    moment, and it does cause problems).
> 
> 3) Return a tag on which queries can be made.
> 
>    This means that you must then have another call to the system to
>    dispose of the tag (and associated system storage). This is
>    unpleasant on a simple blocking receive when you don't want any of
>    the information (since it's another call to the library).
> 
> 4) Have additional (possibly optional) OUT arguments through which the
>    results are returned if required.
> 
>    Using optional keyword arguments in F90 this works fine.
>    C can be made to work more or less.
>    F77 can't (within the standard).
> 
> 5) Have one required argument which is a pointer to a reply structure
>    like that used in 1) which is then filled in by the function.
> 
>    This can work in all the languages.
>    In C you could also allow NULL to mean no such results are
>    required.
> 
> 
> IMHO Solution 5 is best. 
> 
> If we wanted to (and we may) then we could disallow direct access to
> this structure and provide functions to pick it apart (these could be
> macros in C, inline functions in C++). This would avoid having to
> specify the contents of the structure and allow for future expansion.
> 
> 
> 
> -- Jim
> James Cownie 
> Meiko Limited
> 650 Aztec West
> Bristol BS12 4SD
> England

I also like Solution 5 and like the idea of providing functions to access the 
reply structure.  "Hiding" the data structure in this way makes it easy to 
change things in later revisions when we (inevitably) find out we've forgotten 
something.  

Tom Henderson
Forecast Systems Laboratory (NOAA)
[email-masked]