hdf5/testpar/t_ph5basic.c

189 lines
7.0 KiB
C
Raw Normal View History

[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* Copyright by The HDF Group. *
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
* Copyright by the Board of Trustees of the University of Illinois. *
* All rights reserved. *
* *
* This file is part of HDF5. The full HDF5 copyright notice, including *
* terms governing use, modification, and redistribution, is contained in *
* the COPYING file, which can be found at the root of the source code *
* distribution tree, or in https://support.hdfgroup.org/ftp/HDF5/releases. *
* If you do not have access to either file, you may request a copy from *
* help@hdfgroup.org. *
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/*
* Test parallel HDF5 basic components
*/
#include "testphdf5.h"
/*-------------------------------------------------------------------------
* Function: test_fapl_mpio_dup
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
*
* Purpose: Test if fapl_mpio property list keeps a duplicate of the
* communicator and INFO objects given when set; and returns
* duplicates of its components when H5Pget_fapl_mpio is called.
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
*
* Return: Success: None
* Failure: Abort
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
*
* Programmer: Albert Cheng
* January 9, 2003
*
*-------------------------------------------------------------------------
*/
void
test_fapl_mpio_dup(void)
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
{
int mpi_size, mpi_rank;
MPI_Comm comm, comm_tmp;
int mpi_size_old, mpi_rank_old;
int mpi_size_tmp, mpi_rank_tmp;
MPI_Info info = MPI_INFO_NULL;
MPI_Info info_tmp = MPI_INFO_NULL;
int mrc; /* MPI return value */
hid_t acc_pl; /* File access properties */
herr_t ret; /* HDF5 return value */
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
int nkeys, nkeys_tmp;
if (VERBOSE_MED)
HDprintf("Verify fapl_mpio duplicates communicator and INFO objects\n");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* set up MPI parameters */
MPI_Comm_size(MPI_COMM_WORLD,&mpi_size);
MPI_Comm_rank(MPI_COMM_WORLD,&mpi_rank);
if (VERBOSE_MED)
HDprintf("rank/size of MPI_COMM_WORLD are %d/%d\n", mpi_rank, mpi_size);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* Create a new communicator that has the same processes as MPI_COMM_WORLD.
* Use MPI_Comm_split because it is simplier than MPI_Comm_create
*/
mrc = MPI_Comm_split(MPI_COMM_WORLD, 0, 0, &comm);
VRFY((mrc == MPI_SUCCESS), "MPI_Comm_split");
MPI_Comm_size(comm, &mpi_size_old);
MPI_Comm_rank(comm, &mpi_rank_old);
if (VERBOSE_MED)
HDprintf("rank/size of comm are %d/%d\n", mpi_rank_old, mpi_size_old);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* create a new INFO object with some trivial information. */
mrc = MPI_Info_create(&info);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_create");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
mrc = MPI_Info_set(info, "hdf_info_name", "XYZ");
VRFY((mrc == MPI_SUCCESS), "MPI_Info_set");
if (MPI_INFO_NULL != info) {
mrc = MPI_Info_get_nkeys(info, &nkeys);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_get_nkeys");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
if (VERBOSE_MED)
h5_dump_info_object(info);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
acc_pl = H5Pcreate(H5P_FILE_ACCESS);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
VRFY((acc_pl >= 0), "H5P_FILE_ACCESS");
ret = H5Pset_fapl_mpio(acc_pl, comm, info);
VRFY((ret >= 0), "");
/* Case 1:
* Free the created communicator and INFO object.
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
* Check if the access property list is still valid and can return
* valid communicator and INFO object.
*/
mrc = MPI_Comm_free(&comm);
VRFY((mrc == MPI_SUCCESS), "MPI_Comm_free");
if (MPI_INFO_NULL != info) {
mrc = MPI_Info_free(&info);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_free");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
ret = H5Pget_fapl_mpio(acc_pl, &comm_tmp, &info_tmp);
VRFY((ret >= 0), "H5Pget_fapl_mpio");
MPI_Comm_size(comm_tmp, &mpi_size_tmp);
MPI_Comm_rank(comm_tmp, &mpi_rank_tmp);
if (VERBOSE_MED)
HDprintf("After H5Pget_fapl_mpio: rank/size of comm are %d/%d\n", mpi_rank_tmp, mpi_size_tmp);
VRFY((mpi_size_tmp == mpi_size), "MPI_Comm_size");
VRFY((mpi_rank_tmp == mpi_rank), "MPI_Comm_rank");
if (MPI_INFO_NULL != info_tmp) {
mrc = MPI_Info_get_nkeys(info_tmp, &nkeys_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_get_nkeys");
VRFY((nkeys_tmp == nkeys), "new and old nkeys equal");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
if (VERBOSE_MED)
h5_dump_info_object(info_tmp);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* Case 2:
* Free the retrieved communicator and INFO object.
* Check if the access property list is still valid and can return
* valid communicator and INFO object.
* Also verify the NULL argument option.
*/
mrc = MPI_Comm_free(&comm_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Comm_free");
if (MPI_INFO_NULL != info_tmp) {
mrc = MPI_Info_free(&info_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_free");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
/* check NULL argument options. */
ret = H5Pget_fapl_mpio(acc_pl, &comm_tmp, NULL);
VRFY((ret >= 0), "H5Pget_fapl_mpio Comm only");
mrc = MPI_Comm_free(&comm_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Comm_free");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
ret = H5Pget_fapl_mpio(acc_pl, NULL, &info_tmp);
VRFY((ret >= 0), "H5Pget_fapl_mpio Info only");
if (MPI_INFO_NULL != info_tmp) {
mrc = MPI_Info_free(&info_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_free");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
ret = H5Pget_fapl_mpio(acc_pl, NULL, NULL);
VRFY((ret >= 0), "H5Pget_fapl_mpio neither");
/* now get both and check validity too. */
/* Donot free the returned objects which are used in the next case. */
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
ret = H5Pget_fapl_mpio(acc_pl, &comm_tmp, &info_tmp);
VRFY((ret >= 0), "H5Pget_fapl_mpio");
MPI_Comm_size(comm_tmp, &mpi_size_tmp);
MPI_Comm_rank(comm_tmp, &mpi_rank_tmp);
if (VERBOSE_MED)
HDprintf("After second H5Pget_fapl_mpio: rank/size of comm are %d/%d\n",
mpi_rank_tmp, mpi_size_tmp);
VRFY((mpi_size_tmp == mpi_size), "MPI_Comm_size");
VRFY((mpi_rank_tmp == mpi_rank), "MPI_Comm_rank");
if (MPI_INFO_NULL != info_tmp) {
mrc = MPI_Info_get_nkeys(info_tmp, &nkeys_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_get_nkeys");
VRFY((nkeys_tmp == nkeys), "new and old nkeys equal");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
if (VERBOSE_MED)
h5_dump_info_object(info_tmp);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* Case 3:
* Close the property list and verify the retrieved communicator and INFO
* object are still valid.
*/
H5Pclose(acc_pl);
MPI_Comm_size(comm_tmp, &mpi_size_tmp);
MPI_Comm_rank(comm_tmp, &mpi_rank_tmp);
if (VERBOSE_MED)
HDprintf("After Property list closed: rank/size of comm are %d/%d\n",
mpi_rank_tmp, mpi_size_tmp);
if (MPI_INFO_NULL != info_tmp) {
mrc = MPI_Info_get_nkeys(info_tmp, &nkeys_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_get_nkeys");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
if (VERBOSE_MED)
h5_dump_info_object(info_tmp);
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
/* clean up */
mrc = MPI_Comm_free(&comm_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Comm_free");
if (MPI_INFO_NULL != info_tmp) {
mrc = MPI_Info_free(&info_tmp);
VRFY((mrc == MPI_SUCCESS), "MPI_Info_free");
[svn-r6709] Purpose: Bug fixes/API changes Description: Previously, the Communicator and Info object arguments supplied to H5Pset_fapl_mpio() are stored in the property with its handle values. This meant changes to the communicator or the Info object after calling H5Pset_fapl_mpio would affect the how the property list function. This was also the case when H5Fopen/create operated. They just stored the handle value. This is not according to the MPI-2 defined behavior of how Info objects should be handled. (MPI-2 defines Info objects must be parsed when called.) The old design was trying to avoid numerous duplicates of the same information (e.g., every property object holds one version, every file opened holds another version, when all of them are referring to the same original version.) Nevertheless it is safer to implement it according to MPI-2 definition. Futhermore, the library often needs to do message passing using the supplied communicator. Using the same communicator as the application version may result in some messages mix up. Solution: H5Pset_fapl_mpio now stores a duplicate of each of the communicator and Info object. H5Pget_fapl_mpio returns a duplicate of its stored communicator and Info object. It is now the responsibility of the applications to free those objects when done. H5Fopen/create also stores a duplicate of the communicator and Info object supplied by the File Access Property list. H5Fclose frees those duplicates. There are a few more internal VFL call back functions that they follow this "make duplicates" requirement. Platforms tested: "h5committested". What other platforms/configurations were tested? Eirene (mpicc), sol(mpicc), copper(parallel) Misc. update: Need to update MANIFEST for the added t_ph5basic.c which tests the correctness of duplicated communicator and INFO object.
2003-04-18 11:04:56 +08:00
}
} /* end test_fapl_mpio_dup() */