Thanks for the update. I think the names "reenable_any_source" and "reenable_collectives" should be fine. I like that they mean exactly what they are going to do. I've been sketching out an update on the recovery proposal. So far I don't think the names are going to conflict. Pretty much all the functionality in the recovery proposal includes the names "restore" or "rejoin". And there is a distinction between 'reenabling collectives exclusive of newly restored processes' and 'reenabling collectives inclusive of newly restored processes'. The former is 'reenable_collectives' while the latter is a variation of 'rejoin' (i.e., rejoin_collectives). I should have the new recovery proposal done by Monday (I'll post a note when it is ready). It is a matter of translating my notes to the wiki, and making sure everything still fitst. So maybe we can talk about the interaction between the two proposals on the Wednesday teleconf. -- Josh On Mon, Aug 22, 2011 at 4:02 PM, Darius Buntinas <[email protected]> wrote:
I've updated the wiki with the comments from the last conference call. �Please let me know if I missed anything.
https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizati...
I'm having second thoughts about the names for reenable_any_source and reenable_collectives. �What if we want to add functionality to reenable_collectives in the process recovery proposal to, e.g., restore a process globally if it has been individually restored by one or more processes. �MPI_Comm_reenable_collectives may not be the best name for that function now. �I don't have a good alternative, but here are some candidates for brainstorming:
�MPI_COMM_VALIDATE �MPI_COMM_REPAIR �MPI_COMM_RESTORE �MPI_COMM_RECONCILE �MPI_COMM_CORRELATE �MPI_COMM_NORMALIZE
-d _______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
-- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey