AMPI resumeOnRecv should be a property of the thread, not each comm
Two intertwined issues:
1. resumeOnRecv and resumeOnColl belong to the ampi class, of which there can be multiple instances in an ampiParent, which owns the actual thread to be resumed. Should resumeOnRecv be in ampiParent?
2. AMPI currently uses MPI_COMM_WORLD to lookup its AMPI instance in places, such as when yielding a thread or calling resumeOnRecv. Need to use the actual communicator that the user passed or else shift functionality from ampi to ampiParent.
#2 Updated by Sam White almost 3 years ago
Currently resumeOnRecv is inside the ampi class. Two proposals:
1. Move it inside ampiParent since the thread that is actually resumed on the recv is part of ampiParent anyways. This also gets rid of the need to use a communicator to lookup resumeOnRecv.
2. Move it inside the AmpiRequest class, allowing us to set resumeOnRecv on a per-message basis. What happens
What happens when you have a waitall for both? With #1 whatever the last thing is that touched resumeOnRecv before the waitall will get to determine the resumeOnRecv. Note that this thing could be something that wasn't involved in the waitall. For #2 what do we do if some requests had resumeOnRecv=true and other false? I think if any of them had true then we resume? I think I need to read through all the use cases of resumeOnRecv first...