[Mpi3-tools] Discussion Topics for the MPIT Interface

[Fab Tillier]

Martin Schulz wrote on Sun, 25 Jul 2010 at 14:34:02

> String Interfaces
> ----------------------
> 
> For many API calls, the MPIT interface relies on being able to return
> strings. The only other call (afaik) is MPI_Get_processor_name, which
> uses the following method:
> 
> Define a constant for maximum string length
> OUT parameter for string buffer (written by the routine), which must
> be at least as large as the constant
> OUT parameter for the number of characters written by the routine
> 
> In one of the presentations at the forum, some commented that this is
> not ideal since it can easily lead to buffer overflow.

That was me.

> The suggested
> alternative was to include an IN parameter (or make the length an IN/OUT
> parameter) that allows the caller to specify how long the buffer is.

I prefer a single in/out parameter, but either way would work.

> If this is set to 0, the routine would not copy the string, but instead
> return the size of the string it intends to write. Tools can then
> allocate an appropriate size buffer.
> 
> For MPIT this could be especially useful, since we intend to return
> description texts, which can be long.
> 
> With this we have the following options (please add if there are more):
> 
> - Stay compatible with the rest of the standard and use the techniques
> from MPI_Get_processor_name

I'm strongly opposed to this one, as it requires a recompile of tools for every targeted MPI implementation.

> - Adopt the new interface for all MPIT calls only

I think this is probably the best path forward.

> - Adopt the new interface for all MPIT calls and propose a new routine
> for MPI_Get_processor_name in MPI-3 with the new interface
> - Include both interfaces into MPIT (and propose a matching second
> routine for MPI_Get_processor_name)

I don't see a reason to support both - if someone wants to used fixed size buffers, they only need to initialize the value of the in/out length parameter - no need to dynamically query and allocate buffers if they don't want to (though they will need to handle errors if their buffer is too small.)

> I personally think that we (for now) should stay away of changing
> MPI_Get_processor_name and hence would favor one of the first two
> solutions.

There's more than just MPI_Get_processor_name: MPI_Comm_get_name, MPI_Type_get_name, and MPI_Win_get_name were the first to pop into my mind.  There may be others, I haven't done an exhaustive check.

For now, I would recommend creating a placeholder ticket for these functions in the existing standard, and move forward with the MPIT work using the second option.  We'll have to deprecate the existing functions and create new ones to replace them.

I haven't had time to thoroughly read the MPIT interface definition, but it would be great if we could define it such that there is a clear ABI definition (per target OS at least.)  Fixing the string size issue goes a long way towards this.  For Windows specifically, one aspect that's missing is being explicit as to the function calling convention (I don't know if this is an issue for other operating systems.)

Cheers,
-Fab