Since Jim is not pushing to add more handles to naming, I will not
pursue this unless someone else follows up with a reason to include
it.
> The caching issues are more complex, the basic problem is that many
> implementations use reference counted objects, and there is a
> non-trivial issue about the level at which the cached information
> should live if it is not to be (incorrectly) shared in such an
> implementation.
Rajeev also sent out mail for why he wants caching on MPI_FILE and
MPI_DATATYPE. I would like to see if we can accomodate this in a
reasonable way. I will put off MPI_GROUP, MPI_REQUEST, and MPI_WIN
until later. I think MPI_FILE does not have the problem of reference
counts. My checking of the chapter indicates there are not ways to
create or destroy MPI_FILE except via an open or close. Thus, you
never copy or dup them. Thus, I think we are ok here - do others
agree? MPI_DATATYPE is harder since you build up complex ones from
simplier ones. The issue of reference counts is real. The JOD
currently says that cached values do not propagate in this
circumstance. Thus, I view it as you may have datatype2 that points
to datatype1 for its layout but the cached value on datatype1 is of no
concern. The reference count only applies to the data store. The
implementation has to allow for caching on datatype2 but I not sure
that is a big deal. Am I overlooking something here?
Finally, I note that we have to add new caching functions to deal with
64-bit addresses. Right now this is outlined in miscellaneous since
we removed the new caching capability. I think if there are no
problems or easy ways around them, I would like to add caching to
additional handles to the new 64-bit functions.
Steve