- Added some protection to portions that should only be used when
we're building OMPI (not, for example, when mpicc is being used to
compile a user's MPI application)
This commit was SVN r5082.
Update the unit-test-status matrix to include priority.
Add several new registry diagnostics that helped track down the above bug.
M test/mca/gpr/gpr_triggers.c
M test/Unit-Test-Status.xls
M test/Unit-Test-Status.pdf
M src/mpi/runtime/ompi_mpi_init.c
M src/mca/oob/base/oob_base_xcast.c
M src/mca/ns/base/ns_base_nds_env.c
M src/mca/gpr/replica/api_layer/gpr_replica_dump_api.c
M src/mca/gpr/replica/api_layer/gpr_replica_api.h
M src/mca/gpr/replica/communications/gpr_replica_comm.h
M src/mca/gpr/replica/communications/gpr_replica_remote_msg.c
M src/mca/gpr/replica/communications/gpr_replica_cmd_processor.c
M src/mca/gpr/replica/communications/gpr_replica_dump_cm.c
M src/mca/gpr/replica/gpr_replica_component.c
M src/mca/gpr/replica/gpr_replica.h
M src/mca/gpr/replica/functional_layer/gpr_replica_dump_fn.c
M src/mca/gpr/replica/functional_layer/gpr_replica_fn.h
M src/mca/gpr/replica/functional_layer/gpr_replica_trig_ops_fn.c
M src/mca/gpr/replica/functional_layer/gpr_replica_messaging_fn.c
M src/mca/gpr/replica/functional_layer/gpr_replica_segment_fn.c
M src/mca/gpr/proxy/gpr_proxy_dump.c
M src/mca/gpr/proxy/gpr_proxy.h
M src/mca/gpr/proxy/gpr_proxy_component.c
M src/mca/gpr/gpr_types.h
M src/mca/gpr/base/base.h
M src/mca/gpr/base/unpack_api_response/gpr_base_dump_notify.c
M src/mca/gpr/base/pack_api_cmd/gpr_base_pack_dump.c
M src/mca/gpr/gpr.h
This commit was SVN r5080.
it looks because I re-word wrapped a couple of long comments):
- remove the polling of the event library in all cases where the
condition variables already do so. The condition variables were
updated and I didn't update this code to match. This was only
causing problems because there were some cases where it was
causing deadlock-like things with the orte_wait mutex.
- unlock the orte_wait mutex once we have the status info from
the pid we were waiting on, rather than holding it until the
condition variable can be destroyed. This allows us to poll
a bit more blindly while waiting for the other thread to finish
with the condition signal
- do the condition variable-like unlock / poll / unlock cycle
when progressing the event library when the condition variable
doesn't do it for us.
This commit was SVN r5064.
ompi_mpi_init(): we no longer *query* the components to see what they
can support -- instead, we *tell* the components what they need to
support (if they can't support it, they should disqualify themselves
from selection).
This involved a bunch of things:
- pass the configure-time-decided OMPI_ENABLE_PROGRESS_THREADS and
OMPI_ENABLE_MPI_THREADS constants to each framework selection
function
- eliminate mca_base_init_select_components()
- eliminate all "allow_multi_user_threads" and "have_hidden_threads"
kinds of arguments and aggregation from various framework selection
and component/module functions
- correctly determine the max MPI thread level that we can support and
limit the final MPI thread level as appropriate during
ompi_mpi_init()
As a side effect, while editing nearly every MPI component I also did
the following:
- found 2 places (gm and ib ptls) where ompi_set_using_threads() was
erroneously being called (I think this is left over kruft from
misunderstandings by the original authors). I removed these.
This commit was SVN r5055.
built. The issue is that these tests are trying to test specific
components, and is calling the functions directly -- and therefore
needs to have the component linked in. This is fine when the
component is statically linked as part of libmpi, but presents a
problem when the component is a DSO.
GNU compilers/linkers allow us to link in the DSO as part of the test
executable (and everything "just works"), but this is not portable. A
better solution is going to involve:
- a better unit test support library that can load a DSO on demand
- using function pointers in the unit tests (rather than direct
function invocation)
This commit was SVN r5051.
less confusing (when you have 5-6 parameters, it's easy to mis-count
and have the wrong type if you don't have the associated names).
- Use proper types for the fortran callbacks
- Simplify the predefined Fortran attribute callbacks; do the work
right there rather than calling the predefined C attribute callbacks
(which would simply require further FINT_2_INT / INT_2_FINT
translation anyway)
This commit was SVN r5038.
- Ensure to return properly if we error in the fortran callbacks
- Don't bump the refcount of attributes an extra 1 when we create
them; this just ensures that we never really delete them (oops)
This commit was SVN r5037.
technically speaking, this is a cosmetic change, but having the wrong
parameter names was extremely confusing -- it took me a while (and I
had to cross-reference MPI-1) to figure out that they were wrong, and
I was thinking about the functions incorrectly as a result.
This commit was SVN r5035.
technically speaking, this is a cosmetic change, but having the wrong
parameter names was extremely confusing -- it took me a while (and I
had to cross-reference MPI-1) to figure out that they were wrong, and
I was thinking about the functions incorrectly as a result. Our mpi.h
should have the Right names in order to not confuse users (and
developers!).
This commit was SVN r5034.
