Sessions and attribute caching

[hppritcha]

Problem

Sessions attribute caching was dropped early in the process of getting sessions accepted into MPI 4.0. But now there is renewed interest in possibly putting it back in.

A motivation for this is the utility of the attribute delete callback function. This can be used as a mechanism for cleaning up MPI resources allocated by an application that can be attributed to a particular session.

See discussion in #733 about sessions and keyvals.

Proposal

Add text in the caching section of the groups, contexts, ... chapter describing methods for creating a keyval, associating a value with this key, binding to a session, etc.

Changes to the Text

To be included in a subsequent PR.

Impact on Implementations

Implementations will need to extend their attribute caching mechanism to support caching of attributes on session handles.

Impact on Users

Primarily envisioned for middleware, in particular bindings for modern compilers like julia, rust, and c++. may also be of use for mpi4py.

References and Pull Requests

TBD

[jeffhammond]

Can we join forces and do this for files and datatypes too? Requests and Groups are the only objects where attributes are debatable.

[hppritcha]

Fine with me. In this case I'd like to find an approach which limits API growth. For the 'c' interfaces could we use a more generic approach for treating the handle - like with MPI_T_PVAR_HANDLE_ALLOC? Also if there were some way to just say no to f90, then for f08 we could use polymorphism. I haven't thought much about the copy/delete callbacks though.

I will go ahead with a reading of the PR https://github.com/mpi-forum/mpi-standard/pull/1129 at the next forum to see what arises and serve as a seque to a broader discussion.