Capturing return values from concurrent mpiexecs

[Pete Wyckoff]

martin.schaffoener at e-technik.uni-magdeburg.de wrote on Wed, 09 Nov 2005 19:38 +0100:
> On Tuesday 08 November 2005 21:06, Pete Wyckoff wrote:
> > Here's a little patch to CVS that seems to work here, at least for
> >     ./mpiexec -server &
> >     ./mpiexec --comm=none -n 1 /bin/false
> >
> > Let me know if it seems to work for you and I'll check it in.  I
> > think that the modified file hasn't been changed much since 0.80
> > so it should patch cleanly to that distribution.
> 
> It does the trick. It applied to 0.80 with a constant offset of -1.

Okay, finally got around to checking in this bugfix.

> > Hrm, now that I think of it, is there any way that a pure server
> > can exit cleanly?  Shouldn't it always return 1?  Let me know if
> > you have any ideas.
> 
> Hm. If it is sent a signal to make it stop, I think it should exit cleanly if 
> there are no connected clients. Otherwise, it should exit with an error. Or 
> maybe it should just warn when sent SIGTERM if clients are still connected 
> and continue running. In that case, maybe SIGKILL should be necessary to 
> force it to stop.

I made the -server exit with status 0 if no clients were connected
when it was hit with a SIGTERM (or HUP or INT), as you suggested.
It exits with 1 after killing off existing tasks and clients if
there were still some connected.  I'm not too fond of programs that
don't die when you hit Ctrl-C, so I didn't do the warning thing.

Thanks for finding the bug and for this useful suggestion.  It'll
appear in the next release, and is in the CVS now.

		-- Pete