Yes, MochiCommunicator will support non-blocking send/recv. I was looking at IceT right now and I was actually thinking that I could write an IceT communicator that rely on vtkCommunicator, so that any non-MPI implementation (not just ours) would be supported. It’s good that you let me know about the need for non-blocking functions.
Would that be useful if I contribute such an IceT communicator anyway? Maybe you could add a member function in vtkCommunicator to query which features (such as non-blocking send/recv) are supported by the actual implementation. Wherever IceT is used, instead of downcasting to a vtkMPICommunicator, you would first check if the vtkCommunicator has the right feature, and use a VTK-based IceT communicator implementation instead?
(The alternative is that we write an IceT communicator specifically for our library, and we would have to patch VTK anyway to prevent it from downcasting to MPI).
EDIT: I actually see non-blocking send/recv implemented in the vtkMPICommunicator, here…?