Error clases

[dalcinl]

As of now, the value of error classes (other than MPI_SUCCESS and MPI_ERR_LASTCODE ) is assigned by listing the names in alphabetical order. I don't really like this approach, as it is not future-proof. As soon as a new MPI standard adds a new error class, the order will be broken.

I would like to propose an slightly alternative approach:

• We group error classes by the major.minor version of the standard in which they appeared.
• Within each group, we subgroup them by its prefix MPI_ and MPI_T_,
• Within each subgroup, we sort alphabetically by name to generate a list.
• From that list, we assign values from 1,...,N. Of course MPI_STATUS is first with value 0.
• We can still keep the MPI_T values in a separate range, let say starting as 1000 as now, although I would rather prefer the first one be 1001' , such that errclass % 1000is positive. I'm still thinking about the convenience of this separate range. It may not play well with user-defined error classes and theMPI_LASTUSEDCODEattribute toCOMM_WORLD`.

I can easily get the MPI_ prefixed error class groups by MPI major.minor version from the mpi4py source tree :

grep '#define PyMPI_HAVE_MPI_ERR_' src/lib-mpi/config/mpi-*.h

I don't have the MPI_T ones, but these are just a few, it is not hard to do.

Related, I would like to reconsider the case of MPI_ERR_LASTCODE. Our proposal right now follows the Open MPI approach, where MPI_ERR_LASTCODE leaves (a bit) of room for extension, but it is still a relatively small integer. MPICH, on the other hand, uses a large value of 0x3fffffff. I see little benefit on the Open MPI approach. IMHO, After the introduction of user-defined error classes and code, MPI_ERR_LASTCODE became a bit obsolete. I would like to propose defining MPI_ERR_LASTCODE at least as large as 32767, or even INT_MAX if there are no objections.

Comments?

[jeffhammond]

We should try to omit MPI_ERR_LASTCODE from the ABI. It doesn't serve the apparent purpose unless it is a version and/or implementation-dependent tight (?) upper bound on the number of error codes.

Setting MPI_ERR_LASTCODE to INT_MAX means it is useless. Omitting it from the ABI is a less aggressive alternative.

[dalcinl]

For MPICH folks, it is effectively useless, they use a very large value. I'm not sure omitting thing from the ABI is a good idea. I'm inclined to think that is better to define it to INT_MAX (which IIUC would be backward compatible regarding the MPI standard), deprecate it, and tells users to rely on the attribute query mechanism.

[jeffhammond]

What is gained by setting it to INT_MAX versus saying that it is not specified in the ABI? I just don't understand the use case where this would be better.

[jeffhammond]

For starters, what code are people writing that depends on MPI_ERR_LASTCODE?

[dalcinl]

Probably no correct code uses it, it's useless, and it has been useless since MPI-2. But you cannot simply remove it, at best you can deprecate it. I'm just a bit worried of leaving things out of the ABI.

PS: mpi4py uses it, but in an unusual way. For exampe, if you build mpi4py with an MPI-4 implementation, then the value of MPI.ERR_HANDLER in Python will map to MPI_ERR_LASTCODE to signal "not available in the backend MPI implementation". But I could very well use a negative number instead.

[qkoziol]

I believe that Jeff isn’t saying to get rid of it from the standard, but rather to not include it in the ABI specification. Therefore, implementations could set it to whatever value they’d like. Jeff, is this correct? Quincey On Apr 17, 2023, at 5:01 AM, Lisandro Dalcin ***@***.***> wrote: Probably no correct code uses it, it's useless, and it has been useless since MPI-2. But you cannot simply remove it, at best you can deprecate it. I'm just a bit worried of leaving things out of the ABI. PS: mpi4py uses it, but in an unusual way. For exampe, if you build mpi4py with an MPI-4 implementation, then the value of MPI.ERR_HANDLER in Python will map to MPI_ERR_LASTCODE to signal "not available in the backend MPI implementation". But I could very well use a negative number instead. — Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABICDQSCGCDFNKV6W3WVYCTXBUIGDANCNFSM6AAAAAAWX6S4K4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dalcinl]

Yes, I understand that. But then we now will have two categories of MPI symbols/constants. Those that are in the ABI, and those that are not. I have the hope of making all of the MPI API part of the ABI, without any exceptions.

[jeffhammond]

I have relented from excluding it from the ABI. We just need to pick a suitably large value to avoid backwards compatibility issues in the future. The slack discussion in #general is relevant to this.