3

This is a follow-on question to How do I free a boost::mpi::request? . I'm noting odd behavior when listening for lists rather than individual items. Is this my error or an error in boost? I'm using MSVC and MSMPI, Boost 1.62. I'm pretty sure that it's not behaving properly on the wait for a cancelled job.

If you try version B with mpiexec -n 2 then you get a clean exit - if you try version A, it hangs indefinitely. Do you all see this as well? Is this a bug?

#include "boost/mpi.hpp"
#include "mpi.h"
#include <list>
#include "boost/serialization/list.hpp"

int main()
{
    MPI_Init(NULL, NULL);
    MPI_Comm regional;
    MPI_Comm_dup(MPI_COMM_WORLD, &regional);
    boost::mpi::communicator comm = boost::mpi::communicator(regional, boost::mpi::comm_attach);
    if (comm.rank() == 1)
    {


        //VERSION A:
        std::list<int> q;
        boost::mpi::request z = comm.irecv<std::list<int>>(1, 0, q);
        z.cancel();
        z.wait();


        //VERSION B:
//      int q;
//      boost::mpi::request z = comm.irecv<int>(1, 0, q);
//      z.cancel();
//      z.wait();

    }
    MPI_Comm_disconnect(&regional);
    MPI_Finalize();
    return 0;
}
Carbon
  • 3,828
  • 3
  • 24
  • 51
  • An even more interesting case is possible in which you have a struct using friend class boost::serialization::access - if you use BOOST_IS_MPI_DATATYPE, the behavior differs. – Carbon May 22 '17 at 14:08

1 Answers1

1

This is clearly a bug in Boost.MPI.

For serialized types, like std::list, the cancel is forwarded from request::cancel() to request::handle_serialized_irecv, which does not specify a proper handling for ra_cancel.

Zulan
  • 21,896
  • 6
  • 49
  • 109