functions return an invalid fortran handle (-1) if an invalid C handle
is passed in.
Just so it's logged somewhere -- it looks like commit 2 of 2 as noted
in the r9560 commit message (ok, 3 of 3 if you're really counting),
where we have to edit the C interface functions to check for NULL, is
going to be far easier than I thought -- many (but not all) of the C
interface functions already check for NULL MPI handles (either
directly or through helper functions).
Woo hoo for foresight...
This commit was SVN r9561.
The following SVN revision numbers were found above:
r9560 --> open-mpi/ompi@e00c6053dc
handling of invalid Fortran handles. Per MPI-2:4.12.4, if we get an
invalid Fortran handle, we should return an invalid C handle. Before
this commit, we checked if the fortran handle index was out of range
(i.e., <0 or >sizeof(array)). If so, we used to return MPI_*_NULL
(i.e., a valid C handle). But to be faithful to MPI-2:4.12.4, we
now return NULL (an invalid C handle).
If the fortran index is in bounds but is an index for an MPI object
that has already been freed, the code already returns NULL because the
entry in the array will be NULL (i.e., we already did what
MPI-2:4.12.4 said for this case).
Hence, this commit makes the handling of invalid fortran handles in
the MPI_*_F2C functions be uniform: we always return NULL.
Commit 2 of this will be to edit just about every C interface function
(!) to ensure that MPI handles are not NULL. Otherwise, if the user
calls a fortran interface function with an invalid handle, the fortran
interface function will call MPI_*_F2C and blindly pass the result to
the back-end C function. The C function will eventually end up trying
to dereference it -- segv. Having a run-time check for NULL and
invoking an MPI exception is far more social (e.g., the user can get a
stack trace out of MPI_ABORT) and consistent (i.e., we're already
checking for MPI_*_NULL in the C interface functions).
Since all the C interface functions have all the machinery for
run-time parameter checking, and they all already check for
MPI_*_NULL, it's easy enough to add another check for NULL.
This commit was SVN r9560.
thread, which will do progress independently of MPI. So in this case we
have to call opal_event_loop instead of opal_progress.
This commit was SVN r9551.
event library (since the event library has its own thread). So when
we are using progress threads, we really want to call opal_event_loop()
and not opal_progres().
This commit was SVN r9549.
as I understand how that one works and don't really understand what
was in the amd64 code (which was copied from before I started working
on the inline assembly). This fixes the race condition we were
seeing on PGI causing test failures
* sync non-inline assembly with inline assembly version
This needs to go to the v1.0 branch
This commit was SVN r9539.
to use the appropriate macro for all the Fortran .TRUE. handling, or
things get misinterpeted and, with some compilers, it will look like
the attribute wasn't copied properly.
This commit was SVN r9536.
implementations. I dont want to overload the memcpy functions,
therefore people interested in using the high performance memcpy
should use directly opal_memcpy instead. Notice, that there are 2
other versions of memcpy available, which use a destination or a source
described as iovecs.
This commit was SVN r9532.
follow the statement from the standard that make the most sense to me. In this
particular case this statement is:
If there is no active handle in the list it returns outcount = MPI_UNDEFINED.
This commit was SVN r9512.
* Add a platform spec for using the portals reference implementation's
RTE instead of our own to make local testing easier.
* Add a cnos rmgr component so that 1) we don't have to build nearly
as many components (no need for ras,rds,pls,etc.) and 2) calls
to MPI_ABORT() won't print error messages about not being able to
contact the daemon. Still need to fill in some of the terminate
stuff with calls from cnos, but will come in time.
* Make gpr_null use the base code for creating value and keyval
structures so that we don't segfault in ompi_mpi_init().
This commit was SVN r9510.
We support all the events in the PERUSE specifications, but right now only one event
of each type can be attached to a communicator. This will be worked out in the future.
The events were places in such a way, that we will be able to measure the overhead
for our threading implementation (the cost of the synchronization objects).
This commit was SVN r9500.
still in the obsolete files, just in case they rollback the specification in order to
allow event for anything else than communicators.
This commit was SVN r9498.
Not much got tested that wasn't already - I've uncovered a connection
establishment deadlock and wanted to get these changes committed before I
attack it.
The big changes:
- Moved much of the connection code from btl_udapl_component.c to
btl_udapl_endpoint.c.
- Cleaned up initialization of various fragment members.
- MCA_BTL_UDAPL_ERROR macro, which is compiled in/out appropriately.
This commit was SVN r9496.
MPI_ABORT. From the ompi_info output:
MCA mpi: parameter "mpi_abort_delay" (current value: "0")
If nonzero, print out an identifying message when
MPI_ABORT is invoked (hostname, PID of the process
that called MPI_ABORT) and delay for that many seconds
before exiting (a negative delay value means to never
abort). This allows attaching of a debugger before
quitting the job.
MCA mpi: parameter "mpi_abort_print_stack" (current value: "0")
If nonzero, print out a stack trace when MPI_ABORT is
invoked
This commit was SVN r9487.
