Thanks, John. I've read through it quickly and I have a few comments.
Page 3: What are the units of the value in MPIR_proctablesize?
(bytes, elements, ints, ...)
Page 3: An MPIR_Event is introduced. Is this the definition of an
MPIR_Event? It might be best to have a separate definition first.
Page 4ff: MPICH 1 should probably be written as MPICH-1 or MPICH1 or
just MPICH (the MPICH<space>1 is awkward).
Page 5ff: mpirun vs mpiexec . Its true that mpirun is the most
common name, but mpiexec has been the preferred and *official,
standard sanctioned* name for over 12 (!) years. I'd like the
document to recognize that mpiexec is the correct name for the program
that may be used to start MPI programs, and mention that mpirun is non-
standard, but historical and still widely used, name.
Page 8, Table 1: Thank you! (I haven't gone through it in detail, but
this is a great thing to have)
Page 11, first line: "is specified a set" should be either "specified
a set" or "is specified as a set".
Page 11, definition of VOLATILE. I'm concerned about this. First, it
requires that VOLATILE be defined as empty if __STDC__ and __cplusplus
are not defined - shouldn't volatile be allowed if supported? More
seriously, if volatile is not supported, can the interface work? If
so, then why include VOLATILE?
Page 11, MPIR_PROCDESC description. Is the pid an int (unknown size)
or an int of a specific size? The text suggests that it is an int of
an unspecified size (the tool must determine). May be worth a
reminder to implementors, particularly on systems where ints may be
different sizes depending on compilation options.
Page 12ff: const, volatile, and the declarations. I think we should
look over the declarations carefully to see whether they should
include const and/or volatile . For example, MPIR_debug_state is
declared without volatile - shouldn't volatile be used for any
variable that (a) may be changed and (b) read by another agent (such
as the debug tool)? There's also one array declaration that uses
"char MPIR_dll_name[];"; the others all use pointers ("char
*MPIR_debug_abort_string") (not counting the ones that allocate
storage, e.g., char MPIR_executable_path[256]), which itself seems
dangerously small.
All in all, an excellent and valuable start. Thanks, John!
Bill
On Feb 27, 2010, at 11:39 AM, John DelSignore wrote:
> Hi all,
>
> Attached is DRAFT copy of a document in PDF format that contains a
> description of the MPIR Process Acquisition Interface. I think it's
> still pretty raw and there's more information and clarification
> needed, but it is fairly complete and should serve as solid
> foundation material for a more formal interface description that
> could be incorporated into the standard. I can be prepared to
> discuss this paper during the March 2010 meeting, if the MPI-3 Tools
> Workgroup deems it appropriate.
>
> Note that to date, I have made no effort to more formally document
> the MPIR Message Queue Display Interface. I inserted a placeholder
> at the end of the attached document as a reminder that this is a TO-
> DO item.
>
> Cheers, John D.
> <MPIR Process Acquisition Interface.pdf><ATT00001..txt>
William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign
