Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] add_procs
From: George Bosilca (bosilca_at_[hidden])
Date: 2009-02-05 15:40:52

This functionality has as many chances to be called as any MPI 2
dynamics MPI functions. Every time the MPI universe is expanded, once
the modex of the new processes is known, add procs is called in order
to allow the PML and BTL to update their local view of the MPI universe.

The code is robust and well tested by a lot of people (please check
the maling list about spawn problems). Unfortunately, as you noticed,
the current incarnation of sm doesn't support spawn. If there is any
changes to be made, adding support for spawn in sm is the direction in
which we should look, as sm is the only BTL today that doesn't support
dynamic processes.


On Feb 5, 2009, at 14:41 , Eugene Loh wrote:

> BTLs have "add_procs" functions. E.g., my own parochial interests
> are with the sm BTL and there is a mca_btl_sm_add_procs() function.
> I'm trying to get a feel for how likely it is that this function
> would be called more than once. There is code in there to support
> the case where it's called multiple times: e.g., don't just call it
> once during MPI_Init, but again during program execution to add more
> processes.
> Maybe we can do this the "multiple choice" method:
> A) That code is in there for standard purposes (dynamically added
> processes or something?) and is robust and routinely tested.
> B) That code was in there because we had hoped to support this stuff
> someday, but I'm not sure if it works. It's not really tested and
> rarely used by our users. We should clean it up sometime so that
> we're sure it's doing what it should.
> C) That code was a fantasy we had when we first started coding this
> stuff, and for sure there is no prayer of that stuff working
> properly today or any time in the foreseeable future without major
> work. Come to think of it, we'd be doing ourselves a service by
> ripping all that stuff out.
> _______________________________________________
> devel mailing list
> devel_at_[hidden]