1
1

23 Коммитов

Автор SHA1 Сообщение Дата
Greg Watson
88c4505e6e Enable component by default.
This commit was SVN r6811.
2005-08-11 19:14:24 +00:00
Greg Watson
ad958e3f19 Fix build problem caused by these functions just "going away".
This commit was SVN r6810.
2005-08-11 19:13:09 +00:00
Tim Prins
36435cbe4a a small change to make this configure test right.
This component is ompi_ignored so no need to autogen.....

This commit was SVN r6807.
2005-08-11 14:29:40 +00:00
Ralph Castain
4e79a51395 Add a job_info segment to the system that holds a container for each job. Within each container is a keyval indicating the job state (i.e., all procs at stage1, finalized, etc.). This provides a rough state-of-health for the job.
This required a little fiddling with a number of areas. Biggest problem was that it uncovered a potential for an infinite loop to be created in the registry. If a callback function modified the registry, the registry checked the triggers to see if anything had fired. Well, if the original callback was due to a trigger firing, that condition hadn't changed - so the trigger fired again....which caused the callback to be called, which modified the registry, which checked the triggers, etc. etc.

Triggers are now checked and then "flagged" as being "in process" so that the registry will NOT recheck that trigger until all callbacks have been processed. Tried doing this with subscriptions as well, but that caused a problem - when we release processes from a stagegate, they (at the moment) immediately place data on the registry that should cause a subscription to fire. Unfortunately, the system will just hang if that subscription doesn't get processed. So, I have left the subscription system alone - any callback function that modifies the registry in a fashion that will fire a subscription will indeed fire that subscription. We'll have to see if this causes problems - it shouldn't, but a careless user could lock things up if the callback generates a callback to itself.

Also fixed the code that placed a process' RML contact info on the registry to eliminate the leading '/' from the string.

This commit was SVN r6684.
2005-07-29 14:11:19 +00:00
Tim Prins
b7ab5f1ec8 only compile the bproc soh component if we are on bproc 4
This commit was SVN r6625.
2005-07-27 22:13:21 +00:00
Tim Prins
384639c5cc - more build system updates for bproc
This commit was SVN r6609.
2005-07-26 22:12:03 +00:00
Tim Prins
70587299f3 - respect configure options --without-bproc and --with-bproc=no
- check for a recent version of LANL bproc by looking for sys/bproc_common.h

This commit was SVN r6596.
2005-07-22 22:41:35 +00:00
Tim Prins
73171fb09d - added configure.m4 so we only compile the bproc soh component if we have bproc
- updated svn:ignore

This commit was SVN r6591.
2005-07-22 14:34:39 +00:00
Greg Watson
986f9e5a07 unignore this component
This commit was SVN r6589.
2005-07-21 22:33:04 +00:00
Greg Watson
4ab9a924aa Avoid multiple calls to update_registry(). Also added sanity check.
This commit was SVN r6588.
2005-07-21 22:31:55 +00:00
Greg Watson
cbb62f4ba3 Tidy up.
This commit was SVN r6529.
2005-07-15 19:54:18 +00:00
Greg Watson
6f38d05a9f Install header.
This commit was SVN r6512.
2005-07-15 04:23:37 +00:00
Greg Watson
7232f648a6 Moved from component header.
This commit was SVN r6511.
2005-07-15 04:23:06 +00:00
Greg Watson
ed8f563a6f Default debug off.
This commit was SVN r6510.
2005-07-15 04:22:35 +00:00
Greg Watson
eaba912169 Only update registry key that actually changed.
This commit was SVN r6509.
2005-07-15 04:22:04 +00:00
Tim Woodall
b30540646a provide the node name when setting status as this may create the node
This commit was SVN r6487.
2005-07-14 15:39:44 +00:00
Greg Watson
de4b8b1a50 New bproc soh implementation.
This commit was SVN r6475.
2005-07-14 00:20:37 +00:00
Greg Watson
a0971116bd Copied from other compenents.
This commit was SVN r6474.
2005-07-14 00:19:41 +00:00
Jeff Squyres
ba99409628 Major simplifications to component versioning:
- After long discussions and ruminations on how we run components in
  LAM/MPI, made the decision that, by default, all components included
  in Open MPI will use the version number of their parent project
  (i.e., OMPI or ORTE).  They are certaint free to use a different
  number, but this simplification makes the common cases easy:
  - components are only released when the parent project is released
  - it is easy (trivial?) to distinguish which version component goes
    with with version of the parent project
- removed all autogen/configure code for templating the version .h
  file in components
- made all ORTE components use ORTE_*_VERSION for version numbers
- made all OMPI components use OMPI_*_VERSION for version numbers
- removed all VERSION files from components
- configure now displays OPAL, ORTE, and OMPI version numbers
- ditto for ompi_info
- right now, faking it -- OPAL and ORTE and OMPI will always have the
  same version number (i.e., they all come from the same top-level
  VERSION file).  But this paves the way for the Great Configure
  Reorganization, where, among other things, each project will have
  its own version number.

So all in all, we went from a boatload of version numbers to
[effectively] three.  That's pretty good.  :-)

This commit was SVN r6344.
2005-07-04 20:12:36 +00:00
Brian Barrett
170ef8af1f * rename ompi_show_help to opal_show_help
* rename ompi_stacktrace to opal_stacktrace
* rename ompi_strncpy to opal_strncpy

This commit was SVN r6336.
2005-07-04 02:38:44 +00:00
Brian Barrett
39dbeeedfb * rename locking code from ompi to opal
This commit was SVN r6327.
2005-07-03 22:45:48 +00:00
Brian Barrett
761402f95f * rename ompi_list to opal_list
This commit was SVN r6322.
2005-07-03 16:22:16 +00:00
Jeff Squyres
1b18979f79 Initial population of orte tree
This commit was SVN r6266.
2005-07-02 13:42:54 +00:00