> Don't the generalized attr_get, attr_put, and attr_delete functions need
> an argument to tell what type of MPI handle is being handed to the
> function?
That's definitely a viable way to handle it. I was thinking that an
implementation could do something like:
[..]
Certainly an implementation should be free to ignore any information
that it knows it doesn't need, but I was thinking that the attr get,
put, and delete functions might be request type specific.
Upon thinking about this further, this may not work since some
handles may actually be pointers (e.g., MPI_COMM), while others are
actual structures (e.g., MPI_STRUCT) in C.
Given the list of handle types is fairly exhaustive, is it intended that
caching be doable with *every* opaque or semi-opaque type? If so, then
what about packages that want to work with MPI? Assuming some form of
generalized requests gets approved (and I hope it does), then won't that
necessitate having a way to register new handle types and register
handle specific get, put, and delete functions?
[I'm thinking specifically about MPI-IO and handles of type MPIO_File.]
> Also, I thought that MPI_STATUS wasn't going to be one of the handle
> types since it isn't opaque.
Yes, that was what was generally agreed upon; however, I wanted
to bring it back up for discussion since I believe it may be useful
to cache things on a status (for example, in a wait/waitall/waitsome
function where the request handle is returned as NULL the cached
information could be temporarily transfered to the status handle).
MPI_STATUS is partially opaque -- information other than that in the
two visible fields may be kept in MPI_STATUS.
Good point.
David