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.
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.
set after we call mca_pml.pml_comm_add(). This allows us, in the
destructor, to only call mca_pml.pml_comm_del() if the corresponding
pml_comm_add() was called. In this way, if an error occurs during the
construction of a communicator (e.g., attributes failing to copy, as
in the Intel test MPI_Keyval3_c), we simply propagate the error up the
stack so that an MPI exception can be generated -- not cause a failed
assert() in teg's pml_del_comm().
This commit was SVN r5032.
more obvious (and documented)
- VERSION now has lots of comments in it
- separate out whether we want the SVN r number in the version and
what the SVN r number is
- clearly describe the process for building the full version number
string
- make ompi info have a separate line item specifically for the SVN r
number, regardless of what the version number is
- update "make dist" process to substitute in the SVN r version
This commit was SVN r5022.
interface is unchanged):
- the first call to OBJ_CONSTRUCT and OBJ_NET on a given class is now
thread safe
- fix memory leaks for the vtable constructor / destructors;
orte_finalize() makes a call to free all the memory allocated for
that stuff. After ompi_class_finalize(), any calls to OBJECT
functionality will be met with a swift, painful SEGV death!
This commit was SVN r5017.
- check return value correctly when posting non-blocking recvs
- use any values that have been set in the global structs as the
defaults when registering mca parameters - this prevents any
values that have been set in the structs from the command line
parser from being overwritten
This commit was SVN r5011.
