Ralph Castain 4510b42638 Hold the RMGR in the spawn command until the application process actually launches. Previously, we returned from spawn immediately after launching the daemons - this meant that the caller had to define their own "wait until app launches". This only tells the caller that the app procs were launched, of course - it doesn't mean that they have started execution or reached any particular stage. However, for non-MPI procs, this is as far as we can go - there is no further stage gate we can provide. ... Still, better than what we provided before... This commit was SVN r14554.		2007-05-01 11:27:36 +00:00
..
configure.params	Remove unneeded PARAM_INIT_FILE variable in configure.params files used by	2007-01-08 03:44:22 +00:00
Makefile.am	Just like r14289 on the ORTE trunk:	2007-04-12 11:19:42 +00:00
rmgr_urm_component.c	Hold the RMGR in the spawn command until the application process actually launches. Previously, we returned from spawn immediately after launching the daemons - this meant that the caller had to define their own "wait until app launches". This only tells the caller that the app procs were launched, of course - it doesn't mean that they have started execution or reached any particular stage. However, for non-MPI procs, this is as far as we can go - there is no further stage gate we can provide.	2007-05-01 11:27:36 +00:00
rmgr_urm.c	Hold the RMGR in the spawn command until the application process actually launches. Previously, we returned from spawn immediately after launching the daemons - this meant that the caller had to define their own "wait until app launches". This only tells the caller that the app procs were launched, of course - it doesn't mean that they have started execution or reached any particular stage. However, for non-MPI procs, this is as far as we can go - there is no further stage gate we can provide.	2007-05-01 11:27:36 +00:00
rmgr_urm.h	Hold the RMGR in the spawn command until the application process actually launches. Previously, we returned from spawn immediately after launching the daemons - this meant that the caller had to define their own "wait until app launches". This only tells the caller that the app procs were launched, of course - it doesn't mean that they have started execution or reached any particular stage. However, for non-MPI procs, this is as far as we can go - there is no further stage gate we can provide.	2007-05-01 11:27:36 +00:00