Obtain raw MPI_Comm from mpl::communicator about mpl HOT 4 CLOSED

Just to see if it would work (not suggesting you'd adopt this addition or in this way): I did the following on the current master:

diff --git a/mpl/comm_group.hpp b/mpl/comm_group.hpp
index a01fd30..66f9958 100644
--- a/mpl/comm_group.hpp
+++ b/mpl/comm_group.hpp
@@ -280,6 +280,14 @@ namespace mpl {
     MPI_Comm comm_{MPI_COMM_NULL};
 
   public:
+
+    /// \brief Obtain access to underlying mpi communicator
+    /// \return raw MPI_Comm communicator
+    MPI_Comm get_mpi_comm() const
+    {
+        return comm_;
+    }
+
     /// \brief Equality types for communicator comparison.
     enum class equality_type {
       /// communicators are identical, i.e., communicators represent the same communication

This works perfectly for my needs. I can then use this like:

MPI_Intercomm_create(groupcomm.get_mpi_comm(), 0, comm_world.get_mpi_comm(), rl, tag, &intercomm);

Am I doing anything silly here? Are there any mistakes to watch for with regards to the way your library works?

Thanks,

from mpl.

Hi, I would hesitate to incorporate a get_mpi_comm method into MPL. For your usage scenario, it is, however, a reasonable work-around. When you keep in mind the following things, you should not run into trouble: In MPI an object of the type MPI_Commis actually not a communicator, it is just a handle (like a pointer) to a communicator. The actual communicator is not visible to you. In typical MPI applications you can have several handles to the same communicator, which raises ownership issues (Who calls MPI_Comm_free?).

An MPL communicator has also a handle to an MPI communicator and the MPL communicator owns this handle. In MPL there are never two communicators that have handles that point to the same underlying MPI communicator. When a MPL communicator goes out of scope, MPI_Comm_free is called. When and MPL communicator is created by copying, i.e., the copy constructor is called, also a new MPI communicator is created via MPI_Comm_dup.

Therefore, you must never call MPI_Comm_free on a handle that was returned by get_mpi_comm and you must never use this handle after the MPL communicator of which you called get_mpi_comm went out of scope.

from mpl.

Ok, I understand this from your perspective and the points you raised. I certainly use the library due to a number of the points you raised and they are positive.

I guess you can see from my perspective and anyone else in the same boat, via the concrete example and use-case that I'm working through right now, that unless MPL implements every mpi function then this will keep coming up; co-existence of mpi and MPL within the same code base will be tricky.

If you do implement the inter-comm api then this goes away for me, until then i guess I need to retain a local fork.

I was really pleased to see the version contribution to spack. Again, not that straightforward I guess if I'm maintaining a local unversioned fork due to the above requirements.

Many thanks

from mpl.

from mpl.