Ralph Castain 7bee71aa59 Fix a potential, albeit perhaps esoteric, race condition that can occur for fast HNP's, slow orteds, and fast apps. Under those conditions, it is possible for the orted to be caught in its original send of contact info back to the HNP, and thus for the progress stack never to recover back to a high level. In those circumstances, the orted can "hang" when trying to exit. ... Add a new function to opal_progress that tells us our recursion depth to support that solution. Yes, I know this sounds picky, but good ol' Jeff managed to make it happen by driving his cluster near to death... Also ensure that we declare "failed" for the daemon job when daemons fail instead of the application job. This is important so that orte knows that it cannot use xcast to tell daemons to "exit", nor should it expect all daemons to respond. Otherwise, it is possible to hang. After lots of testing, decide to default (again) to slurm detecting failed orteds. This proved necessary to avoid rather annoying hangs that were difficult to recover from. There are conditions where slurm will fail to launch all daemons (slurm folks are working on it), and yet again, good ol' Jeff managed to find both of them. Thanks you Jeff! :-/ This commit was SVN r18611.		2008-06-06 19:36:27 +00:00
..
data_type_support	Initial work on xml support - allocation and job map outputs completed. More to come.	2008-06-04 20:53:12 +00:00
help-orte-runtime.txt	Complete modifications for failed-to-start of applications. Modifications for failed-to-start of orteds coming next.	2007-04-24 20:53:54 +00:00
Makefile.am	ORTE-level MCA params are defined in several places. Ompi_info cannot call orte_init due to an issue with the memory allocator, thus making it impossible for ompi_info to display all of the ORTE-level MCA params.	2008-05-28 13:29:58 +00:00
orte_cr.c	Remove the tags from orte_output_open and the filtering operation from orte_output - this will be handled differently to improve the XML output interface	2008-06-03 14:24:01 +00:00
orte_cr.h	Merge the ORTE devel branch into the main trunk. Details of what this means will be circulated separately.	2008-02-28 01:57:57 +00:00
orte_data_server.c	This commit represents a bunch of work on a Mercurial side branch. As	2008-05-13 20:00:55 +00:00
orte_data_server.h	Merge the ORTE devel branch into the main trunk. Details of what this means will be circulated separately.	2008-02-28 01:57:57 +00:00
orte_finalize.c	This commit represents a bunch of work on a Mercurial side branch. As	2008-05-13 20:00:55 +00:00
orte_globals_class_instances.h	Upgrade the node/orted failure detection code to cover all environments. Use the native environment's capabilities where possible - e.g., SLURM detects orted failure and can report it. Elsewhere, use a heartbeat system to detect orted failure - e.g., for TM and rsh. Heart rate is set via mca param. The HNP checks for callback every 2*heartrate, declares orted failure if not seen in last 2*heartrate time.	2008-06-02 21:46:34 +00:00
orte_globals.c	Initial work on xml support - allocation and job map outputs completed. More to come.	2008-06-04 20:53:12 +00:00
orte_globals.h	Initial work on xml support - allocation and job map outputs completed. More to come.	2008-06-04 20:53:12 +00:00
orte_init.c	Initial work on xml support - allocation and job map outputs completed. More to come.	2008-06-04 20:53:12 +00:00
orte_locks.c	Afraid this has a couple of things mixed into the commit. Couldn't be helped - had missed one commit prior to running out the door on vacation.	2008-03-17 17:58:59 +00:00
orte_locks.h	Add the declspec's in here so that they're visible.	2008-03-17 18:37:03 +00:00
orte_mca_params.c	Initial work on xml support - allocation and job map outputs completed. More to come.	2008-06-04 20:53:12 +00:00
orte_wait.c	Fix a potential, albeit perhaps esoteric, race condition that can occur for fast HNP's, slow orteds, and fast apps. Under those conditions, it is possible for the orted to be caught in its original send of contact info back to the HNP, and thus for the progress stack never to recover back to a high level. In those circumstances, the orted can "hang" when trying to exit.	2008-06-06 19:36:27 +00:00
orte_wait.h	Fix a potential, albeit perhaps esoteric, race condition that can occur for fast HNP's, slow orteds, and fast apps. Under those conditions, it is possible for the orted to be caught in its original send of contact info back to the HNP, and thus for the progress stack never to recover back to a high level. In those circumstances, the orted can "hang" when trying to exit.	2008-06-06 19:36:27 +00:00
orte_wakeup.c	This commit represents a bunch of work on a Mercurial side branch. As	2008-05-13 20:00:55 +00:00
orte_wakeup.h	This commit represents a bunch of work on a Mercurial side branch. As	2008-05-13 20:00:55 +00:00
runtime.h	created opal_version_string and orte_version_string to match the ompi changes	2008-05-20 12:13:19 +00:00