Let me think. How will this work if an old (MPI-2) based app is linked against a new (MPI-3) library? The app has already allocated the MPI_Status and that can't be changed without recompilation that is undesirable. It appears that in this scenario we'll have to have all "old" directly accessible data fields still inside the "new" MPI_Status, with the same sizes and offset/alignment, and then something else, not increasing the MPI_Status size, that can be used for the MPI_Get_count and additional MPI_Get_* functions. E.g., if the "old" internal "count" field (or whatever serves as such) could be "reused" to keep a pointer for all the MPI_Get_* functions - yes, this might work. Needs extra analysis at the implementation level, though. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Greg Bronevetsky Sent: Wednesday, March 24, 2010 5:35 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group; MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: Re: [Mpi3-ft] FT Working Group Teleconf (today)
I agree with Dick. We're getting very strong ISV feedback that an MPI-3 compatibility break will constitute a serious adoption barrier for them.
The other option would be to have an extra function like MPI_Get_count that extracts internal information from MPI_Status objects. Can that be implemented without breaking compatibility? Greg Bronevetsky Lawrence Livermore National Lab (925) 424-5756 [email protected] http://greg.bronevetsky.com _______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.