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 <dholmes@epcc.ed.ac.uk> wrote:
%%PROBLEMWhat are your thoughts? I believe that the structure we have for this text
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.
was inherited from the MPI_Comm_create text.
~Jim.
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.