[Mpi3-bwcompat] ticket 265 udpated

[Jeff Squyres]

I have a terrible thought -- don't shoot me...

What if we don't introduce MPI_Count, but instead introduce the same new functions with explicitly-sized parameters?  E.g.:

int MPI_Type_get_extent64(MPI_Datatype datatype, MPI_Count *lb, uint64_t *extent)

int MPI_Get_elements64(MPI_Status *status, MPI_Datatype datatype, uint64_t *count)

My rationale here is that we have a way to move forward with arbitrary sizes in the future, and MPI implementations don't have to make the (sometimes monumental) decision about changing the size of their MPI_Count datatype.  Specifically: ABI issues are not trifling.  Changing the size of MPI_Count might be a Big Deal to some implementations and (enterprise) customers.  

If the MPI spec needs 128-bit versions someday, we can just add MPI_Type_get_extent128 (etc.).  But the 64 bit versions (and the int version) would certainly still be available with no ambiguity.

The function name implies an explicitly clear size of the parameter, so developers shouldn't get confused at all.  I believe there's also precent for "64" as a suffix in POSIX and other APIs...?

On Mar 2, 2011, at 8:28 PM, Fab Tillier wrote:

> Hi Folks,
> 
> I've updated ticket 265 with the comments from the last meeting.  Please take a look.  We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review.
> 
> TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives.
> 
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265
> 
> -Fab
> 
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat


-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/