Re: comments on I/O chapter
Rajeev Thakur (thakur@mcs.anl.gov)
Wed, 16 Apr 1997 13:37:31 -0500
> From: "Jean-Pierre Prost"<jpprost@watson.ibm.com>
>
> ***********************
> 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.
It is the other way around. MPI_FILE_GET_TYPE_EXTENT will call
dtype_file_extent_fn. Which leads to another point...
If we restrict what datatypes get passed to dtype_file_extent_fn,
such as the etype and its basic datatype, then a user may
implement dtype_file_extent_fn only for those datatypes, and
MPI_FILE_GET_TYPE_EXTENT will work only for those datatypes.
So we need to decide if this restriction is tolerable; else
we have to require dtype_file_extent_fn to work for any basic datatype
and the etype.
Rajeev