X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 10 May 1999 07:17:17 -0500
To: snir@XXXXXXXXXX
From: William Gropp <gropp@XXXXXXXXXXX>
Subject: Re: Question on error handlers
Cc: mpi-core@XXXXXXXXXXX
In-Reply-To: <8525676D.00199C21.00@XXXXXXXXXXXXXXXXXXXX>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: e56b7379a91004f012e3ecc5731ea6b5

At 09:58 PM 5/9/99 -0400, snir@XXXXXXXXXX wrote:
>
>....
>****
>I vote for (b): code above is erroneous. Let's simplify above example:
>
>MPI_Errhandler_create(,... &errhandler);
>myhandler = errhandler;
>MPI_Errhandler_free( &errhandler);
>
>Clearly, we expect that myhandler will contain now a dangling reference -- any
>further use of myhandler is erroneous.

I agree.

>
>Now we have
>
>MPI_Errhandler_create(..., &errhandler);
>MPI_Errhandler_set( comm, myhandler);
>MPI_Errhandler_get( comm, &myhandler);
>MPI_Errhandler_set(comm, otherhandler);
>MPI_Errhandler_free( &errhandler);
>
>I dont' see why the fact that the direct assignment to myhandler was 
>replaced by
>a "set", followed by a "get" should make any difference: When the call to
>Errhandler_free occurred, the error handler was not attached to any object.
>Therefore, the error handler can be deleted as soon as the Errhandler_free
call
>occurred and any subsequent use of errhandler is erroneous. An interpretation
>saying that the "free" cannot take course until all communicators the error
>handler was ever attached to are freed sounds strange to me.
>

Here are two sets of rules that are consistent and easily to apply:

choice a:

create: set reference count to 1.
free: decrement reference count by 1
set: increate reference count of error handler being set by 1, decrease
reference count of replaced error handler by 1
comm_free: decrement reference count of error handler by 1.
comm(create of various types): increment reference count of error handler by 1

(this is what the standard says now).
When the reference count goes to zero, the error handler is deleted and
cannot be used again.

choice b:

same rules as choice a, with

get: increment reference count by 1

Both sets of rules are simple; choice b has the two advantages that it is
symmetric with respect to get and set, and it allows 
for easier modularity between one software package that creates a
commuicator (with attached error handlers and attributes) and one which
makes use of the error handler.  

>The example you gave has the "free" even earlier. It basically is
>
>MPI_Errhandler_create(..., &errhandler);
>MPI_Errhandler_set( comm, myhandler);
>MPI_Errhandler_free( &errhandler);
>MPI_Errhandler_get( comm, &myhandler);
>MPI_Errhandler_set( comm, otherhandler));
>
>Mover the Errhandler_free call earlier cannot improve things -- cannot
increase
>the lifetime of the error handler. Any subsequent use of myhandler is 
>erroneous.
>

I don't understand your point here.

>
>If an errorhandler is not continuously attached to a communicator -- so
that it
>exists, at times, "unattached" to the communicator, then the error handler
>object should not be freed up front.  The warning is that once the
errorhandler
>object is freed, it may be deleted as soon as it is not attached anymore
to any
>object.
>

I agree.  The point is that in code made up of modules from several places,
it can be difficult to promulgate all of the rules and constraints, and
even more difficult to ensure that those rules are followed.  By making get
symmetric with set (with respect to creating a "use" of the error handler,
which, after all, it does), we make it easier to perform a basic operation
(temporarily replacing an error handler with another, for example, with
MPI_ERRORS_RETURN).  We can stick with choice (a) because that is what is
in the standard, but I believe that the standard would be better if we had
chosen choice b.  

Bill