Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] Open-MPI rewrite

Dunno what to tell you at this time. One of the lead OMPI developers got back to me late last week (I've been out of town the last 5 days or so) and tells me we need to redesign the entire proxy system to work with their code.

Here's a snippet of his response:
I don't know of any simple solution here. We really don't want the daemon
reading nodes into that segment until we are ready to spawn - that's the
whole point of the dynamic discovery procedure.

I honestly don't know why your code used to work - it shouldn't have done so
except in a Bproc environment. What I would suggest is that you modify your
code to handle the case where there is nothing on the node segment.
I am thinking you should move on without me as I try and rearrange the proxy to deal with this new environment. I'll rewrite my Java code or something later. We need to talk about this in person obviously and get some advise. This problem is getting harder, not easier.

-- Nathan
Correspondence
---------------------------------------------------------------------
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndebard@xxxxxxxx
---------------------------------------------------------------------



Randy M. Roberts wrote:
Nathan,

I'm waiting for your commit before committing my changes.  We are
probably hitting the same sources, e.g. ModelManager.  (In fact, I would
like to refactor ModelManager into an abstract base class with separate
subclasses for each type of model.)  Some of my changes are small, so I
thought that you should commit first, since it may be easy to gloss over
my many small changes during a CVS merge.  If I do refactor ModelManager
without your changes being first committed, then all heck will break
loose during a merge.

If it does not seem likely that you will be committing to HEAD in
the near future, then I have two alternate suggestions.

1) Create a new branch for your work.  I'll merge my changes from my
   branch into your branch.  When your branch stabilizes we will merge
   your branch to HEAD.

2) I will merge to HEAD without your changes.  Later you can commit
   to HEAD, but there may be a lot of small error-prone conflicts to
   iron out, and a big headache with the ModelManager refactoring.

I would prefer the first option, but if your changes are not anticipated
to be stabilized enough to commit to HEAD for a long time, then this
may not be the best option. If you have other alternatives, let me know.

advTHANKSance,
R^2


Back to the top