[Mpi3-ft] WG call on tuesday aug. 9, 3pm est

[Aurélien Bouteiller]

As food for thoughts, here are the initial findings we have come to at UTK, regarding the items discussed at the forum: 

MPI_COMM_ALLGET_FAILED (or whatever name it may come about): 
- Can be implemented by users (tedious, but doable: could be provided as an helper support lib, or standardized on its own later if deemed useful; bottom line, missing this API does not reduce features or limit expressivity) 
- Has no use case that we can think of, so it maybe is a hammer looking for a nail? 
+ Can be used to do the COMM_CREATE_GROUP trick (but it is unclear what the advantage is with regard to SHRINK, as this ALLGET_FAILED will cost the same as the expensive part of SHRINK).

We are wary of feature creep. If it is not absolutely necessary, we'd advocate not having it. We'd like to see more realistic use cases where shrink is not the appropriate answer before looking further. 


I/O etc: 
* It is very difficult to define a clear meaning for what is the status of a file pointer when multiple async I/O are ongoing. The I/O do not have to necessarily be in-order, so it might end-up that some later posted I/O will succeed while early one fail, during the  same completion call. The status of the file pointer is very 
difficult to define in such a case (and the implementation could turn into a nightmare).
* The file pointer can be reset by FILE_SEEK. This is a local function, so the end-user can keep using it to restore the value of the file pointer to something meaningful, corresponding to the status of its file operations. 

Shared pointers: impossible to tackle in any meaningful way. These are collective operations in the true sense, it should not be expected to be able to continue collective operations on an object (here the file) which has reported failures.

Summary: there is no real problem. The pointer being undefined is not a blocker, it can be reset with seek, and (non-collective) operations continued, without much trouble. 


Lets discuss this tomorrow, 
Aurelien 








Le 8 juil. 2013 à 09:01, Aurélien Bouteiller <bouteill at icl.utk.edu> a écrit :

> Dear WG members,
> 
> This is a reminder that according to our planning, we are having our regular phone meeting tomorrow at 3pm EDT. 
> 
> 
> Date: July 9,
> Time: 3pm EDT/New York
> Dial-in information: 218-339-4600
> Code: 623998#
> 
> 
> Next Meetings:
> * July. 23, 2013
> * August. 6, 2013
> 
> 
> --
> * Dr. Aurélien Bouteiller
> * Researcher at Innovative Computing Laboratory
> * University of Tennessee
> * 1122 Volunteer Boulevard, suite 309b
> * Knoxville, TN 37996
> * 865 974 9375
> 
> 
> 
> 
> 
> 
> 

--
* Dr. Aurélien Bouteiller
* Researcher at Innovative Computing Laboratory
* University of Tennessee
* 1122 Volunteer Boulevard, suite 309b
* Knoxville, TN 37996
* 865 974 9375