it's always required.

the same socket.

buffers now, not fd's directly. This allows the bootstrap layer to
multiplex data within the same socket and just hand over the
demultiplexed data to the upper layers.

functional yet, but it looks like the bootstrap interface is not rich
enough to handle cases where a single socket is shared for both stdout
and stderr. We'll keep this commit as a WIP and fix the bootstrap
interface first.

can use it with the persistent daemon code as well.

confusion.

can be shared between different executables.

explicitly disable it from mpiexec. The PMI server automatically
checks for this case and uses the upper level PMI information
appropriately.

rely on processes with pipes for everything.

all. This needs to be completely moved to the bootstrap layer.

an error.

not deal with the entire proxy structure. Parts that the bootstrap
server creates and destroys (stdio fds, pids) should not be exposed to
the upper layers.

of dynamic processes. Attempting to move the persistent launching
capability to the bootstrap server completely and remove any
information corresponding to it in the upper layers.

The idea is to have a separate daemon that plays the role of
ssh/rsh/slurm on systems where any such daemon is not available. It
just boots a process and forwards stdout, stderr, stdin (no Hydra
specific information). The upper layers will always talk to this
daemon as in their "runtime mode". As a bonus, we also get the ability
for multiple jobs to share the persistent daemons and the ability to
add security/authentication later.

Current status: Runtime launching works correctly, but the bootstrap
interface is quite broken making the persistent launch part
difficult. It expects too much information that is of no use to the
bootstrap servers. We'll leave the code in this commit as a WIP
(persistent launching is in a broken state) and get back to it after
fixing the bootstrap interface. The hydserv persistent daemon is yet
to be added.

functional yet since we need some more changes in the infrastructure
to deal with dynamic spawning requirements. The PMI callbacks (or even
the regular PMI process launching portion) should not have to deal
with we being in persistent mode vs. runtime mode, etc. All this logic
should be in the bootstrap servers.

be used by PMI-1 as well.

is not specified by the user.

generalization.

upfront and were using the fact that the vector is not NULL as a test
to see if the proxy is done.

only PGID 0, but the code to allow for more PGIDs is in place.

a single process group. This is required for dynamic process support.

information in the proxy handle.

maintaining it in the top-level Makefile.

value.

If the process mapping string is longer than what PMI expects, we were
aborting. Depending on what the user's host configuration is, the
length factor might not be avoidable. We now gracefully fallback to
the PMI-1.0 behavior and report that we do not understand the key.

getting updated correctly.

README, since we are planning to expose this capability in the next
release.

Thanks to Eric Borisch for reporting this bug.  Broken since r5484.

No reviewer.

Fixed a major bug in Hwloc binding

BG/P DUAL mode is limited to a maximum 2 threads per process.  This
change modifies the threads/comm/dup_leak_test and threads/pt2pt/threads
tests to tolerate creating fewer threads.

No reviewer.

We weren't actually running the new op_commutative test in the test
suite, so it wasn't even getting built on a "make testing".  As it turns
out, there were compilation errors.

Thanks to Joe Ratterman for catching this.

No reviewer.

mpd code anyway.

Reviewed by goodell.