--------------167E2781446B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
-- Dick Treumann IBM RS/6000 Division (Internet) treumann@pok.ibm.com Poughkeepsie, NY (VNET) TREUMANN at KGNVMC Tel: (914) 433-7846 (internal) treumann@windsurf.pok.ibm.com Fax: (914) 433-8363--------------167E2781446B Content-Type: text/plain; charset=us-ascii; name="final" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="final"
I have had little time to review the May 8 dreft and what little time I have had in now over. Here are comments on the first part of the document. The rest I have not reviewed at all this time.
references are page:line-line
2:38 Remove: and handlers
3:8-9 The last sentence is no longer true
4:41 Fotran -> Fortran
6:27 The first two -> The first five
7:46 This says that an opaque object is no longer accessible after a MPI_Whatever_free is made on it. The new, never voted, semantic of MPI_Request_free on a GR directly violates this.
9:8-13 Is there really any use of this concept in the body of the document? I looked at MPI_ERRHANDLER_SET and did not see any discussion of the errorhandler being a "state". I do not recall the concept elsewhere either.
11:17 add: To avoid conflicts with case insensative languages which may use lower case for external names, also avoid mpi_ and pmpi_.
12:4 spelling: descriptions, not descritions
18:16 "or not" adds nothing to the intent.
18:21 I suggest second sentence become "Unless there has been a call to MPI_ABORT, each ....."
18:40-43 repeats same info that is above the example.
18:48 Consider adding word "operation" before "completion"
19:28 first word shoind be If, not In
21:12 Make {Test,Wait}_{all,some} caps and add any
21:18 TEST_ANY -> TESTANY
22:20-23 Wording is awkward - maybe: The MPI 1 standard specifies the output argument of MPI_TYPE_SIZE in the C binding as type int. The MPI Forum has considered proposals to change this and decided to reiterate the original decision.
23:1-6 Does this say that it is erroneous for a copy or delete function to return anything other than MPI_SUCCESS? We may have chosen to beg the issue of what sort of error is reported when there is a non-0 return but did we really intend to label user programs which return error codes as no longer correct?
24:22, 25:24, 26:3 remove the word Fortran
29 The handle type MPI_Errhandler should be added to list of handle types. Pg 214 in changebar copy of 1.1 which is what I have handy.
33:20 Chapter 4 does not read like it has "relaxed" something. How about saying we "extended" the model? To me, "relax" is something like saying "MPI 1.1 did not allow MPI_Foo to be used on fribbles but MPI 2 relaxed this restriction."
36:10-11 "(group,rank) identification is not unique" is ambiguous because (group,rank) does identify a unique process, it is not the unique identifier for the process. Maybe: "(group,rank) is not a unique identifier"
Several pages not reviewed .........
55:12-? Are keys and values case sensitive? I did not see an explicit statement on this and I think there should be one.
63:1-2 What does an MPI which does not exist in a Berkley sockets environment do? Does it not provide the entry point at all, treat a call as a fatal error or politely return MPI_COMM_NULL? I do not care which but think the standard should say.
63:3-4 Since MPI states that interaction between MPI and non-MPI modes of interprocess communication is undefined, can we imply that MPI_COMM_JOIN is OK between processes which share a MPI_COMM_WORLD or MPI parent/child relationship? I think this should say: The processes must not have a preexisting MPI connection.
67:32 span, not spawn
67:36-40 MPI_Type_extent should be mentioned.
68:30 All other MPI_Whatever_free functions are local and lazy and not collective. MPI_File_close is similar to MPI_Win_free in that it is collective and non-local, possibly blocking. Resources are recovered before it returns. I think the use of "free" in the name MPI_Win_free confuses the issue and MPI_Win_close would be better.
69:44 Suggest rephrasing "than we need to needlessly add" to say "then we must add otherwise unneeded"
72:1-5 Note that a remote window is sized in bytes while a put/get uses datatypes, remotely interpreted. The amount of information and evaluation required to locally decide if a put/get of a arbitrary type at a remote task in a heterogeneous environment may be quite substantial.
82:28 I do not understand what this sentence is trying to convey. there are certainly similarities but not "equivelence" as far as I can see.
That is as far as I got. Vacation is upon me.
--------------167E2781446B--