[mpich-discuss] where is two-phase I/O implemented

[Dries Kimpe]

* Matthieu Dorier <matthieu.dorier at irisa.fr> [2013-05-01 11:41:52]:

> Alright :-)

> Thanks for your answers. If I understand correctly, for instance when
> performing a strided read, ADIOI_GEN_ReadStridedColl is called,
> optimizes the access and then call ADIOI_BGL_ReadContig itself (possibly
> several times)?

> Btw how does Mpich knows which ADIO backend to use, in general? (and
> more specifically how does ADIOI_GEN_ReadStridedColl knows that it has
> to use ADIOI_BGL_ReadContig?) Does it have something to do with the fact
> that for instance with PVFS2 when the kernel module is not used, the
> filename should be prefixed by pvfs2:// ? If I want to develop a new
> ADIO backend, how can I make it such that filenames prefixed with
> myfilesystem:// will use this backend? (Maybe there's a documentation
> for that somewhere?)

Sort of the way virtual functions are implemented in C.
There is a struct of function pointers (ADIOI_Fns_struct);
The ADIO_File structure (and others) has a pointer to it.


Then there is a set of wrapper functions that tries to find the pointer to
the ADIOI_Fns_struct based on the arguments passed to the function.

For example, 

#define ADIOI_OpenColl(fd, rank, access_mode, error_code) \
	(*(fd->fns->ADIOI_xxx_OpenColl))(fd, rank, access_mode, error_code)

so, when calling ADIOI_OpenColl the ADIOI_Fns_struct gets located through
the fd argument (identifying the file), and then the macro calls the
specific function for this file.

If openfile wans to call the independent open function (or any other
ADIOI_Fns_struct function), the same will happen.

  Dries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130501/5d8dc946/attachment.sig>