Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] add_procs
From: Ralph Castain (rhc_at_[hidden])
Date: 2009-02-05 15:30:41

I would only add that we should be certain that the code is -not-
called more than once as this could cause problems. We don't currently
have a way for dynamically spawned procs to share memory with their
parents - if that code does get called, I would worry that it hadn't
been tested and could cause memory issues.

On Feb 5, 2009, at 1:26 PM, Richard Graham wrote:

> I would leave the code alone. The intent was for (A), but it is not
> used
> for that. It is not in the performance critical region, works
> correctly as
> we use it today, and putting it back later on would be a hassle not
> needed.
> Rich
> On 2/5/09 2:41 PM, "Eugene Loh" <Eugene.Loh_at_[hidden]> 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]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]