[Mpi-comments] Comments on MPI 3.0 draft 2 [part 2]

[George Bosilca]

Dear Jeremiah,

Thank you very much for your detailed comments on the chapters I maintain. I agree with most of your suggested changes, and I have applied them. A patch with the required changes have been sent to the gatekeepers.

  Thanks,
    george.


On Aug 19, 2012, at 18:06 , Jeremiah Willcock <jewillco at osl.iu.edu> wrote:

> Page 335 lines 28-29: Are these constants required to be macros (rather than const global variables), and do they need to be defined exactly as shown?  Otherwise, someone could write "#define MPI_VERSION 1+2" or (in C++) "static const int MPI_VERSION = 3;".

We want them to be used in #if, so they should be #define

> Page 336 line 46: "value" should be "values".
> 
> Page 337 line 8: What is "myrank"?
> 
> Page 337 line 12: "implementation specific" should be "implementation-specific".
> 
> Page 337 line 23: There should be a comma before "inclusive".
> 
> Page 337 line 41: There should not be a comma before "I/O".
> 
> Page 341 line 26: "pointer" should be "pointers".
> 
> Page 341 line 48: This text should end with a period, and be on the same page as the code.

Done.

> Page 342: What is the return value of an error handler used for?  Is it meaningful at all? Is it guaranteed that, if an MPI function returns at all after an error, its return value is the same (implementation-defined) error code that was passed to the handler?

The prototype of error handlers is defined on page 344 at line 11, and there is no return value.

> Page 342 lines 35-36: "Thus, if the user chooses not to control error handling, every error that MPI handles is treated as fatal." is not true for I/O.

The text implies MPI errors. What is the I/O specific error that is treated differently?

> Page 342 lines 40-41: "non trivial" should be "non-trivial".
> 
> Page 343 line 29: "implementation" should be "implementations".
> 
> Page 344 line 16: "stdargs" is not a standard term.

I would use varargs instead. Not very standard either, but it is a minimal change improving readability.

> Page 349 lines 44-45: Line 45 appears to be redundant with the last part of line 44.

Repetition is the mother of all learnings syndrome …

> Page 357 line 6: "high-resolution" should be "high resolution".  Also, this text might want to repeat the wording from Annex A that MPI_{Wtime,Wtick} can be macros and/or not go through the profiling interface.

There is a reference to the section that describe them as macros.

> Page 357 line 18: The discussion of MPI_WTIME_IS_GLOBAL should refer to the section where it is defined.

OK.

> Page 357 lines 34-: MPI_INIT_THREAD is not mentioned here; this seems like the logical place to describe it.

We can't just reference it, we will have to describe the function and the prototype. It is a larger change, more than I would accept at this stage.

> Page 359 line 38: There is extra space in the middle of the line.

Tis seems to be an issue with one of our environments leaving trash behind. We will investigate more.

> Page 359 line 45: There should be a comma after "MPI_REQUEST_FREE".
> 
> Page 359 line 48: "operations" should be "operation".
> 
> Page 360 lines 1-2: Are there any requirements that particular objects be freed before MPI_FINALIZE?

Not imposed by the standard itself.

> Page 361 line 31: Who/what does "they" refer to?
> 
> Page 362: Both functions on this page have extra whitespace in their abstract signatures.
> 
> Page 362 line 41: There should be a comma after "accepted".
> 
> Page 363 lines 1 and 7: "error code" should be in sans-serif.

OK.

  Thanks,
    george.