Ralph Castain deb2470ba3 Move the waitpid callback in the bproc pls *after* we store the daemon info. Otherwise, a short-lived app could terminate before we store the daemon info, causing mpirun to not terminate the daemons since the call to get_active_daemons would return a NULL list. ... This commit was SVN r12656.		2006-11-22 22:49:22 +00:00
..
configure.m4	Update the copyright notices for IU and UTK.	2005-11-05 19:57:48 +00:00
configure.params	Update the copyright notices for IU and UTK.	2005-11-05 19:57:48 +00:00
help-pls-bproc.txt	Update the copyright notices for IU and UTK.	2005-11-05 19:57:48 +00:00
Makefile.am	Here is the major MAD-cure commit. I have written plenty about it, so I refer you here to those messages for a description of everything that was done.	2006-09-14 21:29:51 +00:00
pls_bproc_component.c	Bring the timing instrumentation to the trunk.	2006-10-25 15:27:47 +00:00
pls_bproc_state.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
pls_bproc.c	Move the waitpid callback in the bproc pls *after* we store the daemon info. Otherwise, a short-lived app could terminate before we store the daemon info, causing mpirun to not terminate the daemons since the call to get_active_daemons would return a NULL list.	2006-11-22 22:49:22 +00:00
pls_bproc.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