Setup the event API to support multiple bases in preparation for splitting the OMPI and ORTE events. Holding here pending shared memory resolution.
This commit was SVN r23943.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
as an argument to a macro which could result in it
being called twice. I did not observe any issues,
but it should be fixed. Also did some minor refactoring
for clarity and following code convention.
This commit was SVN r23886.
Mostly TAB to spaces changes, though a couple style fixes were included as well.
The tab/space issue was causing problems with off-trunk branch merging.
This commit was SVN r23827.
This merges the branch containing the revamped build system based around converting autogen from a bash script to a Perl program. Jeff has provided emails explaining the features contained in the change.
Please note that configure requirements on components HAVE CHANGED. For example. a configure.params file is no longer required in each component directory. See Jeff's emails for an explanation.
This commit was SVN r23764.
Also, some other changes to bring the csum PML up
to date with changes that happened in ob1 over the
last two years. This includes a few bug
fixes and some minor refactoring.
This commit was SVN r23757.
omp_get_thread_num -> MY_THREAD
omp_get_num_threads -> THREAD_NUM
to avoid conflicts with the 'omp.h' of the PGI compiler version 10.0.x
This commit was SVN r23748.
All interface APIs for accessing the info remain unchanged in opal/util/if.c.
This has been tested on Mac, Linux, and NetBSD. Nobody else seemed interested in testing it, so there may be some future problems revealed as people try it on other OSs.
This commit was SVN r23743.
that Automake doesn't assume that these are GNU standard packages
that conform to the GNU coding standards. Without this keyword,
Automake can replace the VT INSTALL files with the GNU standard
INSTALL text file.
This change is ''necessary'' for the autogen improvements that are
coming shortly (see
http://www.open-mpi.org/community/lists/devel/2010/09/8478.php); I'm
committing this change ahead of time so that I can pass it upstream to
the VT developers.
This commit was SVN r23740.
* change comm_init API - no need to pass local rank groups, fca calculates that on its own.
* remove local rank list from module - libfca maintains that now.
* in fca_bcast and fca_reduce - pass root rank index and let libfca figure out the local rank index.
This commit was SVN r23716.
of megabytes/s. So we get crazy btl_weights in case of heterogeneous
multirail. And --mca btl_mx_bandwidth <width> cannot work around the
problem (it probably doesn't help because it's overriden by the
runtime link width detection anyway?).
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
This commit was SVN r23712.
administrator can specify compiler flags that get
inserted into the command before the user's flags.
These flags can be specified at configure time.
Reviewed by Jeff Squyres.
This fixes ticket #2474.
This commit was SVN r23709.
update the remain_len field for the buffer.
This really fixes ticket #2532.
This commit was SVN r23706.
The following SVN revision numbers were found above:
r23649 --> open-mpi/ompi@f42c2a737f
Somehow, there's an entire 2nd (identical) copy of the sm btl
configure.m4 in here -- this commit removes the duplicate copy,
leaving only 1 copy of each relevant m4 macro.
Thanks to Ralph for spotting it!
This commit was SVN r23675.
isn't included in the tarball and was only used to generate the
initial f90 scripts -- we've moved well beyond this XML by updating
the scripts without also updating the corresponding XML).
This commit was SVN r23670.
should be "INTEGER(kind=MPI_ADDRESS_KIND)"). This has been wrong for
''years''. Apparently no one who uses the F90 bindings also uses MPI
attributes. Sigh.
This commit was SVN r23664.
NOTE: mmap is still the default.
Some highlights:
o Silent component failover.
o The sysv component will only be queried for selection if it is placed before
the mmap component (for example, -mca mpi_common_sm sysv,posix,mmap). In the
default case, sysv will never be queried/selected.
o Per some on-list discussion, now unlinking mmaped file in both mmap and posix
components (see: "System V Shared Memory for Open MPI: Request for Community
Input and Testing" thread).
o Assuming local process homogeneity with respect to all utilized shared
memory facilities. That is, if one local process deems a particular shared
memory facility acceptable, then ALL local processes should be able to
utilize that facility. As it stands, this is an important point because one
process dictates to all other local processes which common sm component will
be selected based on its own, local run-time test.
o Addressed some of George's code reuse concerns.
This commit was SVN r23633.
a warning itselve (when another warning is generated within the file),
which can be rather anying.
Therefore check for output regarding this unrecognized warning.
This commit was SVN r23624.
MPI_INIT and start of MPI_FINALIZE.
* Clean up MPI Extensions build system to acknowledge that OMPI's the only
project with extensions, as well as remove some build artifacts necessary
for more general components.
This commit was SVN r23616.
string names from MPI_<foo> to MPI_OP_<foo>. While these names are
OMPI-internal-only (i.e., not exposed to MPI applications), this
change is a difference between the released 1.3/1.4 series.
The Voltaire FCA library uses these strings for its own internal
purposes; since the names changed between the 1.3/1.4 series and the
upcoming 1.5 series, it caused a problem for the FCA library. They
volunteered to put in a hot fix in FCA, but it seems to me that we
shouldn't change the names to begin with -- there was no real reason
to change them to MPI_OP_<foo>. So this commit changes them back to
MPI_<foo>.
This commit was SVN r23600.
The following SVN revision numbers were found above:
r20280 --> open-mpi/ompi@4d8a187450
