Hi Josh,
I think we also had another discussion that Darius initiated regarding this. We discussed that we will allow p2p communication on communicator with ‘holes’,
but disallow collectives. Since this seemed to satisfy your use cases. We were thinking about bringing in the validate as an “add-on” ticket. Are we still on track to do that?
Thanks.
===
Sayantan Sur, Ph.D.
Intel Corp.
From: mpi3-ft-bounces@lists.mpi-forum.org [mailto:mpi3-ft-bounces@lists.mpi-forum.org]
On Behalf Of Josh Hursey
Sent: Wednesday, January 25, 2012 12:56 PM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: [Mpi3-ft] MPI_Comm_validate - What's in a name?
On the call today it was suggested that we re-evaluate the name MPI_Comm_validate. It was pointed out that 'validate' seems a bit too close to 'invalid' which is probably not the semantic that we are trying to imply with the name. An alternative
is 'check', but that is a bit close to 'checkpoint' so might not be the best either. So we are looking for a good name.
We started a similar discussion for reenable_any_source, which might lend some ideas:
The semantic behind MPI_Comm_validate [at the moment] are:
(1) A fault tolerant synchronization point returning a consistent value (failed group) at all participating processes
(2) Allow for the posting of new collective operations on the communicator (a communicator with potential holes in it)
Name suggestions are welcome.
-- Josh
--
Joshua Hursey
Postdoctoral Research Associate
Oak Ridge National Laboratory
http://users.nccs.gov/~jjhursey