1) The original text says that "Etype is equivalent to a
dup of the etype used in MPI_FILE_SET_VIEW." I added some
text that says buftype is a equivalent to a dup of the
buftype passed to the read or write function, or else a
a type derived from that buftype. This allows an implementation
to create a derived type to span the user buf if it wants to,
instead of having the filter to do the tiling. The filter
shouldn't care which it does.
However, there is also text later on that says: "The filter
functions will only be passed basic datatypes employed by
the user and complex datatypes that the user has passed to
one of the functions above." I think this is intended to
say that if the program never deals with an MPI_DOUBLE, the
filter doesn't have to worry about translating one.
Unfortunately, this sentence could also be interpreted as
meaning that MPI only passes in the exact datatypes that
the user uses -- no dups, no derived types. Is this
interpretation intended? If so, we need to drop the wording
about dups and derived types. If not, we should change
this sentence.
**********************
I think the intent is the former. User-defined filtering functions only
have
to support datatypes that the user will be using.
**********************
2) I put a discussion item in the text about error codes.
I haven't heard any feedback on it, so I'd like to raise
the question again. Here it is:
What value should a filter return on error? Should it
be predefined, or should the filter allocate error codes as
needed? It would be nice if the filter knew enough not to
allocate a new error code each time it encountered an error,
but where can it cache exisiting error codes? In extra_state?
Then presumably it needs to do locking. Alternatively, the
implementor of a filter could allocate all the necessary error
codes in advance and store them in extra_state for all the filters
to use. The user would then have to call the filter initialization
code. We should offer some guidance here.
***********************
In the latter alternative, what are you suggesting exactly ? That there
is a new user defined function, let us call it init_filter_fn, specified
as an extra argument to the MPI_REGISTER_FILTER interface, and which would
initialize extra_state. Extra_state would contain all possible error
codes that could possibly be encountered when running any other filter
function. This could work pretty nicely since extra_state is passed to all
the user defined filter functions.
***********************
Comments?
***********************
1. I have a few additional comments. How different is etype_file_extent_fn
(renamed by Rajeev dtype_file_extent_fn) from MPI_FILE_GET_TYPE_EXTENT.
Basically, MPI_FILE_GET_TYPE_EXTENT would return the same value than
dtype_file_extent_fn once the data representation has been registered
and associated to the file (using MPI_FILE_SET_VIEW).
Therefore, since the filtering functions will only be called when the user
issues data access calls (and at that point, the data representation is
well known for the file accessed), why do we need dtype_file_extent_fn.
Couldn't the user defined filtering functions use MPI_FILE_GET_TYPE_EXTENT
instead ?
Or is it the other way around ? Given a data representation associated with
a
file, MPI_FILE_GET_TYPE_EXTENT would in fact, for this file, call
dtype_file_extent_fn.
I think the latter seems the correct one, and relates to the missing item
related to MPI_FILE_GET_TYPE_EXTENT.
2. In addition to typos mentioned by Rajeev, the two references to
MPI_REGISTER_HANDLER
should be replaced by references to MPI_REGISTER_FILTER. In the Advice to
users, "interal"
should be "internal".
3. Do the user defined filtering functions have to be written in C, or is
it possible to
define them in FORTRAN. If this is the case, the bindings for
dtype_file_extent_fn,
read_filter_fn, write_filter_fn (and possibly init_filter_fn) should also
be provided
for FORTRAN. And the C bindings should have MPI_ in their names (previous
comment from
Steve).
4. Previous comment from Steve: the C, FORTRAN and C++ bindings for
MPI_GET_REGISTERED_FILTER
have the wrong function/method name.
************************
Jean-Pierre