I have updated the caching proposal that went into JOD. It is late
because the document is late in getting out. I suggest that you all
look at it when it comes out. In that section I discuss the issue of
copying and callbacks. There I say that attributes do not
automatically copy. One reason is that some handle replication
functions take two handle inputs (group union for example) so defining
an automatic way seems dangerous at best. I also mention that copy
callbacks may never be called on some handles. I proposed you can use
any function you want but suggest the NULL ones that are already
provided. I did not explicitly mention what happens if you change an
attribute on one datatype from which another was derived, but since
there is no automatic copying I assumed that it would have no effect
on the derived one. I also said nothing about whether the datatype
had to be committed or not. I view this as a side issue we can settle
once we decide how to do caching - we can kick it around and see what
we think.
Finally, I'll comment on having separate functions for each handle. I
think this is a mistake. We talk about making MPI extensible and
limiting the number of functions. Using a common set of routines for
caching gets us both of these things. I think the way to go is to
limit the list of handles if we want to go that way. The list I had
I considered a laundry list to choose from - not the final say. If
we go with one set of routines, then it will be clear to everyone how
they should expand the set. Either if we have new handles on the list
in the future (notice I didn't say MPI-3 :-) or if implementations
choose to do it as an added feature.
Steve