March 2009 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 19 Mar '09

19 Mar '09

Terry, I'm truly sorry that you find the information that I provide as unreliable. I know that I'm not part of the 'trusted' OpenMPI clan and I wish that there was something I could do to convince you otherwise. If you recall the last forum meeting, I did a complete implementation of the 'const' ticket during that meeting. (and did let everyone know about it). That was an implementation from scratch that did trickle down the constness to all the internal functions of MSMPI. Indeed I did not do any runtime testing at that meeting, it did happen later. However, since MSMPI is not an open source project, I asked the friends at ANL to re-implement it over MPICH2 and make the source available. Since you might not trust my word, you may ask Rajeev and other friends at ANL about this. The tests conducted were checking for regression. Hence, any program that compiled and run correctly before the const change did compile and run correctly after the const change; with multiple compiler and multiple operating systems. We did not conduct any direct tests that are checking the 'constness' of the interface. I don't really know how you check for constness? Do you check that the buffer was not modified? Well that would be testing ticket #45 (send buffer access) and not ticket #46. Do you check that you pass const in and you don't get a compiler error? that relatively simple and I don't think it buys you much (except it verifies that you put the const in all the right places on the interface API). As to rushing this in, I'm curious, this ticket is there for over a year; already implemented twice and tested by two different bodies. Is this really rushing it in? As to the procedural issues. This ticket is one of the first tickets that we had in the system, and of-course as the mpi forum body we did learn a thing or two in that process, unfortunately, first implemented with that ticket. So yes there would be issues. I think that we can resolve these 'issues' but puting dependency on passing this ticket given that we accept the other two corrections to the ticket. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Thursday, March 19, 2009 9:15 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation I am not Jeff and I do not play him on tv but I felt the need to interject my 2 cents. Erez Haba wrote: > Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? > > Possibly but it definitely is biased IMO. > As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. > > Isn't MSMPI based on MPICH? If so how much of the previous work done to support const did you leverage or did you truly reinvent the same wheel MPICH developers did? I guess I find it pretty amazing the applying 10,000 lines of changes and then validating them took you 2.5 hours. > More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). > > > Do the ANL tests and any others really test const-ness without changes. Or are you saying the ANL tests already do explicit testing of const-ness on the right parameters? > With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. > > I would say your information is a useful datapoint but I am curious if what you did really was the full conversion of your MPI implementation to handle this change. > Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. > > For MPICH based implementations I agree it does. For Open MPI I think it is still questionable. I guess I am still interested in the reasoning why shoving this ticket into 2.2 is such a high priority? --td > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > > _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation
by unknown＠example.com 19 Mar '09

19 Mar '09

I am not Jeff and I do not play him on tv but I felt the need to interject my 2 cents. Erez Haba wrote: > Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? > > Possibly but it definitely is biased IMO. > As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. > > Isn't MSMPI based on MPICH? If so how much of the previous work done to support const did you leverage or did you truly reinvent the same wheel MPICH developers did? I guess I find it pretty amazing the applying 10,000 lines of changes and then validating them took you 2.5 hours. > More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). > > > Do the ANL tests and any others really test const-ness without changes. Or are you saying the ANL tests already do explicit testing of const-ness on the right parameters? > With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. > > I would say your information is a useful datapoint but I am curious if what you did really was the full conversion of your MPI implementation to handle this change. > Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. > > For MPICH based implementations I agree it does. For Open MPI I think it is still questionable. I guess I am still interested in the reasoning why shoving this ticket into 2.2 is such a high priority? --td > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > >

1 0

Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation
by unknown＠example.com 19 Mar '09

19 Mar '09

I believe the procedural arguments are the most worrying thing, and they haven't been commented on, which is a bit worrying. Nor has the fact that the proposal, even with *TWO* corrections which are separate proposals, still isn't complete (in that user callbacks which should be const aren't because we're rushing this through 2.2 instead of working in the 3.0 framework, where we could make minor user code changes like correcting const in the callbacks. But in response to your question, Open MPI does have a test suite, and we can use the ANL and Intel test suites. However, none of them test that we're handing const correctly. They test that the behavior according to MPI-2.1 is correct. They don't check that there are const keywords in the right place. Such a change would be fairly large (to the test suite, that is), which only adds to the "largeness" of this patch. We're not ignoring your statement of 2.5 hours. But I don't think that's a realistic metric for doing the implementation, updating/developing test cases, and properly testing on a variety of compilers. Both Jeff and I have asked essentially the same question, without a reasonable answer. Why are we pushing a proposal with known procedural issues and possibly oversized implementation into 2.2 when it can easily be pushed to 3.0? What's the rush - let's do this completely and correctly the first time, rather than looking like fools in two months when it turns out we did something wrong. Brian On 3/19/09 9:50 , "Erez Haba" <erezh_at_[hidden]> wrote: > Jeff, I don't understand why you ignore all the work that has been done with > this ticket and suggest your own metric. Was the information I provided > unreliable or untrue? > > As I said, it took me about 2.5h to implement the entire change on the MSMPI > code base; yes there were many internal functions that had const in it, but > also many that did not. I don't think that by any measure this is a > significant work for any implementer. > > More than that, this interface change was tested using the ANL test suite and > the Intel complete test suite, without a single compile or runtime error over > multiple platforms and compilers. Again, this was not a significant work item; > and I believe that OpenMPI has a regression suite that crosses platform and > compilers which is easy to run (as you described to me many times). > > > With this information that I have already provided before, I don't understand > your claims; unless you think that they are biased and unreliable. > > Hence this ticket completely meets MPI 2.2 requirements in scope and backward > compatibility. > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the > Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation
by unknown＠example.com 19 Mar '09

19 Mar '09

Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 19, 2009 5:20 AM To: Bronis R. de Supinski; MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > I have been quiet on this debate but I am to the point > that I feel a need to speak up. I think the "significant > changes" reason is a canard (I think Brian and Jeff > believe it but it is still a red herring for the most > part). The changes to support it are not significant. > You can implement it by casting it away early. > The changes *are* significant. I count 90 top-level MPI API functions that are affected by this proposal. The bar for 2.2 is "trivial" implementation efforts, no? This is not trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to go above and beyond the requirement and propagate const to lower layers (vs. casting it away immediately), but still -- if a 2.2 change can inspire a 10,000 line diff, that just seems like it doesn't meet the spirit of the "trivial" implementation requirement. Indeed, in doing the "simple" cast-it-away-immediately approach implementation, editing and testing each of the 90 functions will require a good amount of effort. Sure, the first-wave addition of "const" across all of the affected functions is probably relatively easy -- one code monkey and several hours. But how long will it take you to find the one place where you put "const" in the wrong location? How long will it take you to write new tests to verify the const-ness in all the right places? To be clear: it's a "not significant" change to a code monkey. But try to tell your QA guys that this is not significant -- they'll freak out. Hence, if you take the overall scope of both the change and the additional testing to validate this change, this is a large scale implementation effort. I just don't see what the rush is to get this into 2.2. I think Brian makes several good arguments, one of which is: those who want const can put it in today. It hypothetically shouldn't break any existing user codes (this is the code monkey in me talking, not the QA rep), and those implementors who want it for stronger contracts can have it. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation
by unknown＠example.com 19 Mar '09

19 Mar '09

On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > I have been quiet on this debate but I am to the point > that I feel a need to speak up. I think the "significant > changes" reason is a canard (I think Brian and Jeff > believe it but it is still a red herring for the most > part). The changes to support it are not significant. > You can implement it by casting it away early. > The changes *are* significant. I count 90 top-level MPI API functions that are affected by this proposal. The bar for 2.2 is "trivial" implementation efforts, no? This is not trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to go above and beyond the requirement and propagate const to lower layers (vs. casting it away immediately), but still -- if a 2.2 change can inspire a 10,000 line diff, that just seems like it doesn't meet the spirit of the "trivial" implementation requirement. Indeed, in doing the "simple" cast-it-away-immediately approach implementation, editing and testing each of the 90 functions will require a good amount of effort. Sure, the first-wave addition of "const" across all of the affected functions is probably relatively easy -- one code monkey and several hours. But how long will it take you to find the one place where you put "const" in the wrong location? How long will it take you to write new tests to verify the const-ness in all the right places? To be clear: it's a "not significant" change to a code monkey. But try to tell your QA guys that this is not significant -- they'll freak out. Hence, if you take the overall scope of both the change and the additional testing to validate this change, this is a large scale implementation effort. I just don't see what the rush is to get this into 2.2. I think Brian makes several good arguments, one of which is: those who want const can put it in today. It hypothetically shouldn't break any existing user codes (this is the code monkey in me talking, not the QA rep), and those implementors who want it for stronger contracts can have it. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword tothe Cbindings-implementation
by unknown＠example.com 19 Mar '09

19 Mar '09

My post was not a direct reaction to Darius' post; it was more in reaction to the general sense of "we need to pass this" that I've been (perhaps incorrectly) reading into some of the replies. Brian raised several good points in his mail about both procedural and technical issues that I agree need to be addressed before this issue can be passed into law. I see no reason to rush this into 2.2. On Mar 18, 2009, at 11:16 PM, Darius Buntinas wrote: > > Sorry Jeff, I didn't think I was rushing anything. I'm not saying we > shouldn't put it off till 3.0, but I was challenging the lack of const > qualifiers on low-level interfaces as a reason to do so. > > For the record, I do think that the fact that it would require > significant changes in the Open MPI implementation is a legitimate > reason to consider postponing this to 3.0. But we shouldn't wait till > POSIX changes writev to use const qualifiers. > > I wasn't at the last forum meeting, so maybe I missed discussion on > this. So if I'm missing some context, I apologize. I'm not trying to > rush this into 2.2, but I guess I'm not in a rush to push it off to > 3.0 > either. > > -d > > On 03/18/2009 08:24 PM, Jeff Squyres wrote: > > Can someone explain what the rush is to do this for 2.2? > > > > Is there a problem with putting this issue off until 3.0? > > > > > > > > On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > > > >> > >> I just want to point out that casting away the const for low-level > >> interfaces is really a non issue. Putting a const on the send > buffer > >> parameter in an MPI function prototype indicates a contract with > the > >> user that the MPI implementation will not change the contents of > the > >> buffer referenced from that function. As long as the MPI > implementor > >> knows that a routine called by the library will not modify the > buffer > >> it's OK to cast away the const. E.g., the POSIX standard tells > you that > >> writev must not change the contents of the buffer, so casting > away const > >> is fine. > >> > >> Sure, that means that the MPI implementor has to be more careful > when > >> casting away const to ensure that the function being called won't > modify > >> the buffer. But the whole point of the proposal is so that the > >> _MPI_user_ doesn't need to do this and instead can count on the > compiler > >> to do the check. > >> > >> -d > >> _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the Cbindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

All: I have been quiet on this debate but I am to the point that I feel a need to speak up. I think the "significant changes" reason is a canard (I think Brian and Jeff believe it but it is still a red herring for the most part). The changes to support it are not significant. You can implement it by casting it away early. That does NOT eliminate the benefit to the user. Moving any casting that occurs lower does not change the user benefit; it changes the implementer CONFIDENCE that they are in fact conformant. But, if you are conformant you can cast it away immediately without error. Simply put, I have seen no convincing argument that any implementation actually requires significant changes. If implementers want increased confidence, they can delay obtaining that until the time frame they would provide their mistaken level required for conformance for 3.0. Bronis On Wed, 18 Mar 2009, Darius Buntinas wrote: > > Sorry Jeff, I didn't think I was rushing anything. I'm not saying we > shouldn't put it off till 3.0, but I was challenging the lack of const > qualifiers on low-level interfaces as a reason to do so. > > For the record, I do think that the fact that it would require > significant changes in the Open MPI implementation is a legitimate > reason to consider postponing this to 3.0. But we shouldn't wait till > POSIX changes writev to use const qualifiers. > > I wasn't at the last forum meeting, so maybe I missed discussion on > this. So if I'm missing some context, I apologize. I'm not trying to > rush this into 2.2, but I guess I'm not in a rush to push it off to 3.0 > either. > > -d > > On 03/18/2009 08:24 PM, Jeff Squyres wrote: > > Can someone explain what the rush is to do this for 2.2? > > > > Is there a problem with putting this issue off until 3.0? > > > > > > > > On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > > > >> > >> I just want to point out that casting away the const for low-level > >> interfaces is really a non issue. Putting a const on the send buffer > >> parameter in an MPI function prototype indicates a contract with the > >> user that the MPI implementation will not change the contents of the > >> buffer referenced from that function. As long as the MPI implementor > >> knows that a routine called by the library will not modify the buffer > >> it's OK to cast away the const. E.g., the POSIX standard tells you that > >> writev must not change the contents of the buffer, so casting away const > >> is fine. > >> > >> Sure, that means that the MPI implementor has to be more careful when > >> casting away const to ensure that the function being called won't modify > >> the buffer. But the whole point of the proposal is so that the > >> _MPI_user_ doesn't need to do this and instead can count on the compiler > >> to do the check. > >> > >> -d > >> _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the Cbindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

Sorry Jeff, I didn't think I was rushing anything. I'm not saying we shouldn't put it off till 3.0, but I was challenging the lack of const qualifiers on low-level interfaces as a reason to do so. For the record, I do think that the fact that it would require significant changes in the Open MPI implementation is a legitimate reason to consider postponing this to 3.0. But we shouldn't wait till POSIX changes writev to use const qualifiers. I wasn't at the last forum meeting, so maybe I missed discussion on this. So if I'm missing some context, I apologize. I'm not trying to rush this into 2.2, but I guess I'm not in a rush to push it off to 3.0 either. -d On 03/18/2009 08:24 PM, Jeff Squyres wrote: > Can someone explain what the rush is to do this for 2.2? > > Is there a problem with putting this issue off until 3.0? > > > > On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > >> >> I just want to point out that casting away the const for low-level >> interfaces is really a non issue. Putting a const on the send buffer >> parameter in an MPI function prototype indicates a contract with the >> user that the MPI implementation will not change the contents of the >> buffer referenced from that function. As long as the MPI implementor >> knows that a routine called by the library will not modify the buffer >> it's OK to cast away the const. E.g., the POSIX standard tells you that >> writev must not change the contents of the buffer, so casting away const >> is fine. >> >> Sure, that means that the MPI implementor has to be more careful when >> casting away const to ensure that the function being called won't modify >> the buffer. But the whole point of the proposal is so that the >> _MPI_user_ doesn't need to do this and instead can count on the compiler >> to do the check. >> >> -d >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the Cbindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

Can someone explain what the rush is to do this for 2.2? Is there a problem with putting this issue off until 3.0? On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > > I just want to point out that casting away the const for low-level > interfaces is really a non issue. Putting a const on the send buffer > parameter in an MPI function prototype indicates a contract with the > user that the MPI implementation will not change the contents of the > buffer referenced from that function. As long as the MPI implementor > knows that a routine called by the library will not modify the buffer > it's OK to cast away the const. E.g., the POSIX standard tells you > that > writev must not change the contents of the buffer, so casting away > const > is fine. > > Sure, that means that the MPI implementor has to be more careful when > casting away const to ensure that the function being called won't > modify > the buffer. But the whole point of the proposal is so that the > _MPI_user_ doesn't need to do this and instead can count on the > compiler > to do the check. > > -d > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

I just want to point out that casting away the const for low-level interfaces is really a non issue. Putting a const on the send buffer parameter in an MPI function prototype indicates a contract with the user that the MPI implementation will not change the contents of the buffer referenced from that function. As long as the MPI implementor knows that a routine called by the library will not modify the buffer it's OK to cast away the const. E.g., the POSIX standard tells you that writev must not change the contents of the buffer, so casting away const is fine. Sure, that means that the MPI implementor has to be more careful when casting away const to ensure that the function being called won't modify the buffer. But the whole point of the proposal is so that the _MPI_user_ doesn't need to do this and instead can count on the compiler to do the check. -d

1 0