Hey Leo, thanks for taking a peek @ this...
> > Looking at the code, I see no 'setpgid', which is disturbing (to say the
> > least).
>
> Well, there is a setpgrp. That's setpgid(0,0), or something.
Sorry, typo, I meant : os.setpgrp().
> > The logic of this kill means the forked child needs to place itself
> > into it's own process group.
>
> That can never work properly.
No, let's be clear:
1) Main Gump Python process forks
2) Forked child (now) sets it's self as a process group leader [protecting
main Gump], and goes off to run children.
3) Main Gump sets a timer (for 1 hour) to do the call to
os.killpg(os.getpgid(forkedPid),signal.SIGKILL)
IMHO this works. Sorry if I didn't explain it clearly.
> The code in Gump3 responsible for all this is much much simpler, because:
>
> 1) it uses the subprocess module which simplifies things like error code
> handling
> 2) it uses a single global process group for all of gump instead of one
> for each command
> 3) it doesn't use timeouts or any kind of multithreading but only kills
> processes before system exit
> 4) it doesn't bother writing "exec" files
> 5) it does one thing only (we hope it does it well :-D)
The Gump3 start is nicer than Gump2's, I agree. Unfortunately I don't was to
give up on Python 2.3 nor Microsoft (non-Cygwin), and the Process Group
stuff is Posix (not even sure if it works on Cygwin). Hence those lines of
ugly code are not yet removable. Further, we need to make Gump3 start to
kill sub-processes after a timeout (say on a spinning Ant build), or at
least (1) not hang on them indefinately (2) stop them burning CPU if
spinning.
Basically, I'm in a mindset of (1) keep Gump2 "working & generating build
results" (even if not pretty) (2) developing Gump3 much more prettily. As
such, I hope to (one of these days) take the subprocess stuff and do
effectively what Gump2 has per child, in Gump3, but do it in a
clean/subprocess/no-extra-fluff way. Feel free to beat me to it, and/or
review what I submit.
BTW: I merged this patch into LIVE and have a Kaffe run going on Brutus. It
isn't happy about bootstrap-ant, so maybe we'll not see a rogue
compile/test/build causing a (stray) kill to know if it is working.
Hopefully we'll get that soon.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
