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
> 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
> 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
>> 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
>> 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
>> 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
>> devel mailing list
> devel mailing list