That's definitely a viable way to handle it. I was thinking that an
implementation could do something like:
typedef struct {
void *cache;
} MPI_Handle;
typedef struct {
void *cache;
/* other stuff */
} MPI_Comm;
MPI_Attr_put ( handle, ... )
void *handle;
{
MPI_Handle h = (MPI_Handle)handle;
...
}
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.
> 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.
-- Nathan Doss doss@ERC.MsState.Edu