Brian Barrett 33320b7165 Rework the opal_progress interface to better support dynamic processes and at ... the same time, remove some of the MPI-related options from OPAL: - provide mechanism to change at runtime whether sched_yield() should be called when the progress engine is idle - provide mechanism for changing the rate at which the event engine is called when there are "no" users of the event engine (ie, when using MPI but not TCP) - fix some function names in the progress engine to better match their intended use (and remove MPI naming scheme) - remove progress_mpi_enable / progress_mpi_disable because we can now use the functions to set the sched_yield and tick rate interfaces - rename opal_progress_events() to opal_progress_set_event_flag() because the first really isn't descriptive of what the function does and I always got confused by it This commit was SVN r12645.		2006-11-22 02:06:52 +00:00
..
comm_cid.c	The last patch for Windows support. Mostly casting and conversion to C++ friendly headers.	2006-08-24 16:38:08 +00:00
comm_dyn.c	Rework the opal_progress interface to better support dynamic processes and at	2006-11-22 02:06:52 +00:00
comm_init.c	Last set of explicit conversions. We are now close to the zero warnings on	2006-10-20 03:57:44 +00:00
comm_publish.c	The last patch for Windows support. Mostly casting and conversion to C++ friendly headers.	2006-08-24 16:38:08 +00:00
comm.c	Bring over the update to terminate orteds that are generated by a dynamic spawn such as comm_spawn. This introduces the concept of a job "family" - i.e., jobs that have a parent/child relationship. Comm_spawn'ed jobs have a parent (the one that spawned them). We track that relationship throughout the lineage - i.e., if a comm_spawned job in turn calls comm_spawn, then it has a parent (the one that spawned it) and a "root" job (the original job that started things).	2006-11-14 19:34:59 +00:00
communicator.h	Bring over the update to terminate orteds that are generated by a dynamic spawn such as comm_spawn. This introduces the concept of a job "family" - i.e., jobs that have a parent/child relationship. Comm_spawn'ed jobs have a parent (the one that spawned them). We track that relationship throughout the lineage - i.e., if a comm_spawned job in turn calls comm_spawn, then it has a parent (the one that spawned it) and a "root" job (the original job that started things).	2006-11-14 19:34:59 +00:00
Makefile.am	Update the copyright notices for IU and UTK.	2005-11-05 19:57:48 +00:00