[Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation

[Barrett, Brian W]

All -

I agree in sentiment that the const proposal (#46) is a good idea, but I
have a number of concerns with it for the 2.2 effort.

While the diff style increases the patch size, the patch for MPICH is still
rather large.  To properly thread const through an implementation like Open
MPI, which does not use const in the intermediate layers, would be even more
significant.  Further, to take advantage of any interfaces which do allow
use of const would require significant data structure changes inside Open
MPI.  So in terms of work to properly implement this proposal, I have
concerns about this proposal's appropriateness for MPI 2.2, which is
supposed to be for items which "do not require large implementation
changes."

>From a procedural standpoint, choices made in this proposal worry me and set
a poor precedent.  Proposal #46 is incomplete - in order to be a proper
change, additional proposals are necessary (#129 & #130).  Those tickets are
both behind in the process compared to #46 and therefore can not even have
second vote in the same session as #46.  I would feel more comfortable if
the tickets were combined into one and started with the first reading rather
than the current approach.  As I understand it, there is still time for that
choice to be made, and it certainly could have two meetings ago.

Finally, and least significantly, I have concerns about the fact that there
are lower interfaces which will always require casting away const, and will
be (for all practical purposes) unable to change.  The BSD socket layer when
iovecs are in use is a perfect example - the interface is so deeply
established that changing the interface to support const sends (which would
likely require a new data structure) is not feasible.

My preference would be to remove this proposal from consideration from 2.2,
correct it to be a single proposal, and submit it for 3.0.  By then we'll
have more validation the send buffer access restrictions removed in 2.2 were
the right choice, we could fix some of the corner cases in this proposal,
such as user callbacks, and we give MPI implementers time to experiment with
the proposal in their MPI implementations.  Further, I don't believe that
there's a technical reason an MPI implementation couldn't begin marking
those buffers as const today - it shouldn't break user applications and
would allow tightly integrated stacks to avoid some casting ugliness
internally.

Brian


--
   Brian W. Barrett
   Dept. 1423: Scalable System Software
   Sandia National Laboratories