[MPI3 Fortran] Fortran extra_state argument to MPI attribute functions

[Bill Long]

Jeff Squyres wrote:
>
>
> Specifically, there is no indication of how the "extra_state" 
> parameter is handled when it is passed to callback functions.
>
> Bear with me -- this requires a little explanation...
>
> The issue is this: when you create a "keyval" in MPI, you specify 2 
> callback functions and an INTEGER extra_state parameter.  Each of the 
> two callback functions has an extra_state parameter; the intent is 
> that the extra_state from the keyval creation function is passed as 
> the argument to these two callback functions.  Here's a sample keyval 
> creation:
>
>    ! copy_fn and delete_fn are subroutines
>    ! comm is an INTEGER
>    INTEGER extra_state
>    extra_state = 42
>    CALL MPI_Comm_create_keyval(copy_fn, delete_fn, comm, extra_state, 
> ierr)
>    extra_state = 17
>

I read though some sections of the MPI document to try to figure out 
what an "attribute" was - evidently some new component you add to an 
object.  I still don't know what an "attribute key" is - the name 
suggests something to do with encryption. I'll assume that's not 
important.  The document also says that "callback" routines may be 
associated with MPI objects (a communicator in this case).  I'm guessing 
the extra_state is some identifier that is associated with an attribute 
that is created somewhere else.


> However, the original intent is somewhat lost here -- since the 
> MPI_COMM_CREATE_KEYVAL interface specifies that the EXTRA_STATE 
> parameter is an integer, how can you pass a reference to a larger / 
> external structure?  This seems somewhat broken / inconsistent with 
> the intent from the C interface.
>
> Of course, you *could* pass an INTEGER EXTRA_STATE value that is an 
> index into a global array in the application that contains some 
> reference to an external data instance -- but that seems fairly 
> manual.  Is there a better way?
>
> How are such things normally done in Fortran?  (meaning: what *should* 
> we do here?)
>

Assuming my impressions above are close to correct, then I think this is 
yet another example of an underlying defect in the MPI Fortran 
interfaces - the basic denial that derived types exist in Fortran. From 
Fortran's point of view, all of the routines along the lines of 
MPI_Comm_create_keyval should be removed.   Instead, a derived type for 
a communicator, MPI_comm_t, should be defined in the MPI module.  If 
users want to add information to the communicator, they can define a new 
type that extends MPI_comm_t by adding the desired components, and an 
additional interface (and routine, if needed) for the generic binding 
copy_fn that indicates how to copy these components, and add an 
interface to the final binding that performs the delete_fn operation.  
Specify the communicator dummy arguments as class(MPI_comm_t). 

As  historical note,  the POSIX Fortran bindings were written only a few 
years after derived types were added to Fortran, and the debate settled 
on not admitting they existed so as to be "safe".  (There are people 
still using f77!!!, so I'm told the argument went.)  The result is a 
ridiculous mess that's been the butt of derision for years since. And, 
disuse, I might add.  Fortran 2003 has been published for 5 years. We 
should not be afraid to use its features if they turn out to provide the 
"best" solution.

Cheers,
Bill





-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120