> A) [munched]
Yuk. This option is not attractive because it has too many new types.
> B) 3/1: 3 different types of callback functions, but only one type
> of opaque error handler object. In C++ the three typedefs for the
> callback functions are in the namespace of the corresponding class.
C would have 3 typedefs as well -- that's not special for C++.
> We triplicate all functions that deall with callbacks, or with
> communicators, windows of files; namely all error handler functions,
> except MPI_Errhandler_free. [[There is no point in triplicating
> this last function, if there is only one MPI_Errhandler object type
> -- there is no gain in layerability.]] In terms of implementation,
> this means that the opaque error handler object registers which kind
> of callback function is attached to it. We have a run-time type
> matching, rather than compile-time matching: MPI can check, when
> MPI_XXX_ERRHANDLER_SET(handle, errhandler) is invoked, that the
> callback function attached to errhandler is one that takes handles
> to XXX.
But not very elegant. :-)
> C) 1/1: one type of callback function, one type of opaque object.
> The typedef of the callback function becomes, in C,
> errhandler_fn(void * handleptr, void * extra_state,...), where
> handleptr can be, in one version, the MPI handle coerced to void*
> or, in another version, a pointer to the MPI handle coerced to
Here's a breakdown of the two versions:
1) (MPI_Handle) cast to (void *): This works for implementations
that implement handles as integers or pointers. This does not work
for implementations that implement handles as structures (such as the
C++ bindings -- a class is essentially a struct).
2) (MPI_Handle *) cast to (void *): This works for everyone.
So I vote for #2. :-)
> void*. We still triplicate the functions that associate error
> handlers with objects (MPI_XXX_ERRHANDLER_SET,
> MPI_XXX_ERRHANDLER_GET), but we do not need to replicate
> MPI_Errhandler_create and MPI_Errhandler_free. We get, with this
> proposal, a lower function count. We get layerability and
> extensibility: if an implementer adds a new FOO opaque object (e.g.,
> FILE), then it provides MPI_FOO_ERRHANDLER_GET and
> MPI_FOO_ERRHANDLER_SET.
The main reason that I want this is so that implementations can
utilize some code reuse and provide a bit more elegant solution
(especially in C++, whether your C++ implementation is a layer on top
of C or not). There is one minor drawback (see below), but I think
that it is a small tradeoff for the benefit for the implementor.
See my original post for all the nitty gritty details, along with some
corrections by Jean-Pierre:
http://parallel.nas.nasa.gov/MPI-2/mpi-core/0634.html
http://parallel.nas.nasa.gov/MPI-2/mpi-core/0642.html
> There is no way for MPI to do type matching. It's up to the user to
> invoke MPI_XXX_ERRHANDLER_SET(handle, errhanlder) with an errhandler
> object with an attached callback function that takes arguments of
> type XXX.
Which, I think, is a reasonable request. After all, why would you
invoke a File errhandler on a Comm?
{+} Jeff Squyres
{+} squyres@cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"