Hi Jim, I've just read the MPI_COMM_CREATE text in MPI-3.0 and you are correct that the order of statements there is also not ideal. I'm not certain of where the re-read threshold is - that'll be a Forum decision on the day, I guess. Moving a couple of sentences, without changing their content, doesn't seem like a big change to me. Especially when the consequence of the re-positioning is to achieve syntactically what everyone is supposed to assume from the previous ordering. I'll leave it up to you! I certainly don't want to make anyone's life difficult or delay the approval process for end-points. I don't suggest that we try to change the text for MPI_COMM_CREATE, either as part of this ticket or separately. Cheers, Dan. On 16/07/2014 20:28, Jim Dinan wrote:
Hi Dan,
Thanks for the thorough feedback. I applied these changes and attached an updated document. I'm trying to keep the changes we make right now as small as possible so that we can have a first vote in Japan. The change below is reasonable, but I'm concerned that it might push us over the re-read threshold.
On Tue, Jul 1, 2014 at 5:34 AM, Daniel Holmes <[email protected]> wrote:
%%PROBLEM The statements about cached information, valid values for my_num_ep, and the condition for the error code/class all apply to the inter-communicator case as well as the intra-communicator case. Should this be made clearer by moving that text out of the intra-communicator paragraph and after the inter-communicator paragraph? %%SUGGESTION If parent_comm is an intracommunicator ... sum of the values of my_num_ep on all calling processes. If parent_comm is an intercommunicator ... MPI_COMM_NULL is returned in all entries of new_comm_handles. <p>No cached information ... this function will return MPI_ERR_ENDPOINTS at all processes.
What are your thoughts? I believe that the structure we have for this text was inherited from the MPI_Comm_create text.
~Jim.
-- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.