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 [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120