binding/fortran: remove dependency on MPII functions

[hzhou]

Pull Request Description

Remove the dependency on non-standard MPII_Keyval_set_f90_proxy. We handle the fortran param conversions completely inside the fortran binding instead.

Add MPIX_{Comm,Type,Win}_create_keyval_x similar to src/binding/fortran/mpif_h/user_proxy.c. Although MPI_{Comm,Type,Win}_create_keyval has an extra_state for context, but it does not have a destructor callback, which made any context that require cleanup unusable

Note: a destructor callback is necessary if we want allow user to be able to clean up the extra_state even without the consideration for MPI ABI or language bindings. The extra_state is associated with KEYVAL, which is internally reference counted and garbage collected. Without a destructor callback, user won't be able to cleanly destroy the extra_state.

[skip warnings]

Reference: #6965

Attribute semantics across languages

C

int MPI_Comm_set_attr(MPI_Comm comm, int comm_keyval, void *attribute_val);
int MPI_Comm_get_attr(MPI_Comm comm, int comm_keyval, void *attribute_val, int *flag);

But the signature is misleading. The attribute_val in _set_attr is the value of attribute, but in _get_attr is the address of attribute (as value out).

Typical C style. No problem.

Fortran

MPI_COMM_SET_ATTR(COMM, COMM_KEYVAL, ATTRIBUTE_VAL, IERROR)
    INTEGER(KIND=MPI_ADDRESS_KIND) ATTRIBUTE_VAL
    
MPI_COMM_GET_ATTR(COMM, COMM_KEYVAL, ATTRIBUTE_VAL, FLAG, IERROR)
    INTEGER(KIND=MPI_ADDRESS_KIND) ATTRIBUTE_VAL    

Fortran doesn't have the signature difference between _set and _get, always an INTEGER. No problem.

C _set + Fortran _get

Fortran will get an INTEGER. The question is how C sets the integer.

** main branch

int a = 10;
MPI_Comm_set_attr(comm, comm_keyval, 10);

** This PR

MPI_Aint *p_a = malloc(sizeof(MPI_Aint));
*p_a = 10;
MPI_Comm_set_attr(comm, comm_keyval, p_a);

** Alternative
Same as main branch

Fortran _set + C _get

** main branch

int a, flag;
MPI_Aint *p_a;
MPI_Comm_get_attr(comm, comm_keyval, &p_a, &flag);
if (flag) {
    a = *p_a;
}

** This PR
Same

** Alternative

int flag;
MPI_Aint a;
MPI_Comm_get_attr(comm, comm_keyval, &a, flag);

Issue

In old MPICH, MPI_Comm_get_attr returns value or address to a value by remember who sets the attribute and who gets the attribute.

Using standard MPI ABI, there is no mechanism for MPICH to tell which binding sets and which binding gets.

Which interpretation is more sensible

• Who didn't find the requirement of passing in a pointer to a pointer to an int in order to get an int strange?
• In the new interpretation, an attribute is a scalar, period. If user choose to store a pointer as scalar, perfectly fine.
• There is nothing we can do with the established convention of retrieving builtin attributes. Bindings can deal with it as long as it can tell whether a keyval is builtin.

Does this matter

Attributes is for caching (within a design).

Is there any real usage that use attributes across language bindings?

Author Checklist

• Provide Description
  Particularly focus on why, not what. Reference background, issues, test failures, xfail entries, etc.
• Commits Follow Good Practice
  Commits are self-contained and do not do two things at once.
  Commit message is of the form: module: short description
  Commit message explains what's in the commit.
• Passes All Tests
  Whitespace checker. Warnings test. Additional tests via comments.
• Contribution Agreement
  For non-Argonne authors, check contribution agreement.
  If necessary, request an explicit comment from your companies PR approval manager.

[hzhou]

test:mpich/ch3/most
test:mpich/ch4/most