<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Well said. Seconded.<BR>
<BR>
And let's ditch the c++ bindings, too. ;)<BR>
<BR>
-jms<BR>
Sent from my PDA. No type good.<BR>
<BR>
----- Original Message -----<BR>
From: mpi-22-bounces@lists.mpi-forum.org <mpi-22-bounces@lists.mpi-forum.org><BR>
To: MPI 2.2 <mpi-22@lists.mpi-forum.org><BR>
Sent: Wed Mar 18 18:38:55 2009<BR>
Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation<BR>
<BR>
All -<BR>
<BR>
I agree in sentiment that the const proposal (#46) is a good idea, but I<BR>
have a number of concerns with it for the 2.2 effort.<BR>
<BR>
While the diff style increases the patch size, the patch for MPICH is still<BR>
rather large. To properly thread const through an implementation like Open<BR>
MPI, which does not use const in the intermediate layers, would be even more<BR>
significant. Further, to take advantage of any interfaces which do allow<BR>
use of const would require significant data structure changes inside Open<BR>
MPI. So in terms of work to properly implement this proposal, I have<BR>
concerns about this proposal's appropriateness for MPI 2.2, which is<BR>
supposed to be for items which "do not require large implementation<BR>
changes."<BR>
<BR>
>From a procedural standpoint, choices made in this proposal worry me and set<BR>
a poor precedent. Proposal #46 is incomplete - in order to be a proper<BR>
change, additional proposals are necessary (#129 & #130). Those tickets are<BR>
both behind in the process compared to #46 and therefore can not even have<BR>
second vote in the same session as #46. I would feel more comfortable if<BR>
the tickets were combined into one and started with the first reading rather<BR>
than the current approach. As I understand it, there is still time for that<BR>
choice to be made, and it certainly could have two meetings ago.<BR>
<BR>
Finally, and least significantly, I have concerns about the fact that there<BR>
are lower interfaces which will always require casting away const, and will<BR>
be (for all practical purposes) unable to change. The BSD socket layer when<BR>
iovecs are in use is a perfect example - the interface is so deeply<BR>
established that changing the interface to support const sends (which would<BR>
likely require a new data structure) is not feasible.<BR>
<BR>
My preference would be to remove this proposal from consideration from 2.2,<BR>
correct it to be a single proposal, and submit it for 3.0. By then we'll<BR>
have more validation the send buffer access restrictions removed in 2.2 were<BR>
the right choice, we could fix some of the corner cases in this proposal,<BR>
such as user callbacks, and we give MPI implementers time to experiment with<BR>
the proposal in their MPI implementations. Further, I don't believe that<BR>
there's a technical reason an MPI implementation couldn't begin marking<BR>
those buffers as const today - it shouldn't break user applications and<BR>
would allow tightly integrated stacks to avoid some casting ugliness<BR>
internally.<BR>
<BR>
<BR>
Brian<BR>
<BR>
--<BR>
Brian W. Barrett<BR>
Dept. 1423: Scalable System Software<BR>
Sandia National Laboratories<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
mpi-22 mailing list<BR>
mpi-22@lists.mpi-forum.org<BR>
<A HREF="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A><BR>
</FONT>
</P>
</BODY>
</HTML>