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