The “correct” answer is, of course, to propagate the error upwards so that the
highest level caller (e.g., MPI_Init or ompi_info) can return it to the user,
who can then decide what to do.
Disregarding the parameter is not an option as it violates our “do what the
user said to do, else return a
Hello Folks,
This is a followup to the question posed at the SC’16 Open MPI BOF: Would the
community
prefer to have a v2.2.x limited feature but backwards compatible release
sometime
in 2017, or would the community prefer a v3.x (not backwards compatible but
potentially
more features) sometime
Christoph,
This is work in progress. Right now, only the TCP BTL has an integrated
progress thread, but we are working on a more general solution that will
handle all BTLs (and possible some of the MTL). If you want more info, or
want to volunteer for beta-testing, please ping me offline.
Thanks,
Christoph,
if you need progress thread on other interconnects, you might want to
consider an external approach such as APSM
https://www.osc.edu/~kmanalo/asyncrhonousmpi
i was able to download it (or a similar library) a few years ago, but i
cannot recall where ...
Cheers,
Gilles
On Wednesday,
Thank Ralph,
i will take a crack at it, and make the error propagatable.
Cheers,
Gilles
On Wed, Nov 23, 2016 at 3:34 AM, r...@open-mpi.org wrote:
> The “correct” answer is, of course, to propagate the error upwards so that
> the highest level caller (e.g., MPI_Init or ompi_info) can return i
