mpi-forum / mpi-issues

Tickets for the MPI Forum
http://www.mpi-forum.org/
67 stars 7 forks source link

MPI 4.1: MPI_Status_{get,set}_{source,tag,error} and init/finalize #808

Open dalcinl opened 1 year ago

dalcinl commented 1 year ago

Problem

The new MPI_Status_{get,set}_{source,tag,error routines added to MPI 4.1 are are really trivial and intended as a replacement for direct attribute access for the convenience of those using MPI from foreign languages. As Status attribute access, either in C or in Fortran, is something that can be done to initialise a status object before MPI_Init[_thread] and after MPI_Finalize, it would be reasonable to allow MPI_Status_{get,set}_{source,tag,error} to be called outside the init/finalize bracket.

Proposal

Explicitly allow MPI_Status_{get,set}_{source,tag,error} to be called before MPI_Init[_thread] and after MPI_Finalize.

Changes to the Text

Impact on Implementations

None. These routines are simple attribute getters/setters and do not depend on other internal MPI implementation machineries with the exception of error handling for argument. Note that handling of MPI errors on bad argument values (e.g. NULL pointers) outside init/finalize is something that MPI-40 implementations already have to support.

Impact on Users

Authors or MPI bindings for other programming languages will be able to initialize Status objects at any point, outside of the init/finalize bracket.

References and Pull Requests

mpi-forum/mpi-issues#645

jeffhammond commented 1 year ago

I think this should be a chapter committee change and made it into 4.1 because these functions are defined to be equivalent to load/store operations and therefore obviously satisfy the requirement.

wesbland commented 1 year ago

If this were to go into 4.1 at this point, it would need to have a PR today and pass a no-no vote at the next meeting. This is more likely a 4.2 change.

jeffhammond commented 1 year ago

you have the PR today

jeffhammond commented 1 year ago

if we don't get this into 4.1, i will fire up the time machine and make it a 4.1 erratum, because it's absurd not to do this.

wesbland commented 1 year ago

Being a 4.1 erratum is just fine, but we can move forward for 4.1 since it has a PR.