Jim, We talked about it and you agreed after a short explanation. Let me summarize our discussion for the others here.

I have a couple questions about this proposal:

Why MPI_Icomm_dup() and not MPI_Icomm_create()? It seems like MPI_Icomm_create would be more general while still providing the same capability. Comm_create is a generalization of comm_dup and may thus be a more general solution. However, the only use-case that we know is for libraries (comm_dup) and comm_dup provides due to it's limited semantics an easier and potentially better-performing solution.

Why is this crucial for nonblocking libraries? It seems like a synchronous initialization routine for such a library should be sufficient from a functionality point of view. Is this primarily a performance argument? Maybe you can point me to a specific passage in the paper? It's in Section 3.3 in http://www.unixer.de/publications/index.php?pub=135 .

A synchronous initialization would be necessary for *each* communicator *and* needs to propagate upwards in stacked libraries (forcing synchronous initialization of all levels in the call-stack above). This does not compose and can easily create a mess. All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736