Received: from mail.think.com (Mail.Think.COM [131.239.33.16]) by antares.mcs.anl.gov (8.6.10/8.6.10) with SMTP
id OAA05800 for <mpi-external@mcs.anl.gov>; Wed, 2 Aug 1995 14:12:25 -0500
Received: from Thokk.Think.COM by mail.think.com; Wed, 2 Aug 95 15:12:23 -0400
Received: by thokk.think.com (4.1/Think-1.2)
id AA19984; Wed, 2 Aug 95 15:12:22 EDT
Message-Id: <9508021912.AA19984@thokk.think.com>
To: "Nathan E. Doss" <doss@erc.msstate.edu>
Cc: mpi-external@mcs.anl.gov
Subject: Re: Revised generalized cacheing proposal
Date: Wed, 02 Aug 95 15:12:22 EDT
From: David Taylor <taylor@Think.COM>
From: "Nathan E. Doss" <doss@ERC.MsState.Edu>
Date: Wed, 2 Aug 1995 13:24:28 -0500 (CDT)
> 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