Section 9.3.5 of the MPI Standard documentation states:
int MPI_Errhandler_free(MPI_Errhandler *errhandler)
: Marks the error handler associated with errhandler for deallocation and sets errhandler to MPI_ERRHANDLER_NULL. The error handler will be deallocated after all the objects associated with it (communicator, window, or file) have been deallocated.
According to that sentence, is the following pattern correct usage (C++):
MPI_Errhandler errhandler;
MPI_Comm_create_errhandler(custom_error_handler_func, &errhandler);
MPI_Comm_set_errhandler(comm, errhandler);
MPI_Errhandler_free(&errhandler);
// errhandler goes out of scope here..
}
// A lot of code follows here.. then in another function, an MPI command is called on
// the comm (communicator handle), e.g. MPI_Send():
MPI_Send(
&variable,
/*count=*/1,
/*datatype=*/MPI_DOUBLE,
/*dest_rank=*/0,
/*tag=*/SomeTag,
comm
);
That is: will the custom error handler be active for the last MPI_Send()
above even if MPI_Errhandler_free()
was called previously? Just trying to confirm my interpretation of the documentation: That it is safe to free the error handler, as long as the communicator is still alive and holding on to a reference.
All opaque MPI handles are defined this way:
You can free them as soon as you don't want to directly reference them in an MPI function. The implementation needs to take care of the necessary reference counting.
For the error handler, there is not even ref counting necessary, since the implementation can just store the callback function pointer in the communicator descriptor and doesn't even need the error handler object afterwards. The implementation will probably also need to store whether the callback is to C or Fortran because of different calling conventions.
You can later even call MPI_Comm_get_errhandler
to get an error handler handle with the same settings to use it with a different communicator. You should release such handle as well with the free call.