Quincy: A consistent order for MPI_COMM_SELF seems necessary for the functionality that you need. Dick's comments that making it consistent for all communicators makes a lot of sense. If you put in the effort to find the places it needs to be fixed then LLNL would support your proposed change. Bronis On Fri, 3 Apr 2009, Quincey Koziol wrote:

Hi Dick,

On Mar 30, 2009, at 11:00 AM, treumann_at_[hidden] wrote:

...

Message: 3 Date: Mon, 30 Mar 2009 10:09:44 -0400 From: Richard Treumann <treumann_at_[hidden]> Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs To: "MPI 2.2" <mpi-22_at_[hidden]> Message-ID: <OF78D7D349.90931954- ON85257589.004B887F-85257589.004DCBDF_at_[hidden]> Content-Type: text/plain; charset="us-ascii"

I understand that the immediate motive is associated with the use of attribute delete callbacks that occur when MPI_COMM_SELF is freed at MPI_FINALIZE.

That does not alter the fact that when MPI-2 imposed an implicit free of MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete functions for cleanup it involved a narrow extension of a general MPI facility related to attributes and certain object types. To allow attribute delete functions for all other communicators (etc) to occur in arbitrary order while demanding that attribute delete for MPI_COMM_SELF have a standards defined order is an inelegant hack (in my opinion). Freeing MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack because it did not introduce inconsistency.

Add to that the probability that an MPI implementor is likely to use the same algorithms for all attribute management rather than write special case code for MPI_COMM_SELF leads me to argue that if a defined order for attribute delete callbacks is adopted it should be adopted broadly to maintain a consistent flavor across the standard.

If an existing MPI implementation is currently deleting in some other order and an application happens to work on that MPI only because of that order, that application is at least non-portable and probably should be considered buggy. If (or when) the implementation adopts the fifo order for attribute deletes on "user_comm" it would be clear that the implementation change had not "broken the user".

A general mandate that attribute deletion callbacks on all object types must occur in fifo order for an implementation to be MPI 2.2 compliant should not break any "correct" MPI application and should not be noticeably harder for implementors.

It will require tracking down all places in the standard that currently say the order is arbitrary so it is harder to get all ducks in a row for the ticket.

I'm willing to do the work to find the places in the standard which need to change, but need some general feedback about whether this is desired. Any opinions? Personally, I think it would be easier for implementors and more understandable to users to make things consistent across all attributes also, rather than treating MPI_COMM_SELF in a special way for the order of the delete callbacks.

Quincey