Unhandled MPI_Requests generated by mpi_process_group constructor.

[fearsomepirate]

The boost::graph::distributed::mpi_process_group class spawns some non-blocking communication in its constructor, but the resulting requests are never handled. I have tracked this down to the global_trigger_launcher, which has the following comment:

 // TBD: do not forget to cancel any outstanding Irecv when deleted,
 // if we decide to use Irecv

It looks like this was never done, but the default build configuration uses Irecv. To replicate this bug, simply create an mpi_process_group with any constructor, do nothing with it, and let it go out of scope. You will need some way to interact with the MPI profiling interface to detect leaked requests, such as LLNL's mpileaks:

https://github.com/LLNL/mpileaks

[fearsomepirate]

Tagging @DougGregor...I think he wrote this a long time ago, would appreciate any guidance if possible.

[fearsomepirate]

I have found the issue. MPI_Cancel is called on outstanding requests, but MPI_Wait is not. This causes my profiling tool to detect unhandled requests.