On 27-04-2005 00:35, "Adam R. B. Jack" <[EMAIL PROTECTED]> wrote: > 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).
http://effbot.org/downloads/#subprocess http://www.lysator.liu.se/~astrand/popen5/ How bad do you want it? :) > 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. Question: does it matter if the processes are killed after one our or after four hours (the end of a run)? Question 2: do we actually get processes that die so badly they consume loads of CPU? Thinking about this more, when those kinds of ugly errors do occur, they're indeed a problem with the project the command is associated with, and we should be sending them e-mail. The gump2 code integrates those checks and does "model painting" with the results. The gump3 code doesn't. > Basically, I'm in a mindset of (1) keep Gump2 "working & generating build > results" (even if not pretty) (2) developing Gump3 much more prettily. +1! The thing is, when I see a problem with Gump2 that might be easily fixed by code from Gump3 (most likely code from gump.util as that's 99% independent of the rest of gump) it sometimes itches a little. Actually doing "functionality backports" means less disruption during an upgrade and is a good integration test showing loose coupling. > 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. It'd be great if you could take a look at it! Look for the "stupid lambda trick" comment. I'm guessing that's where you want to hook in a different process group, starting the timer soon after. Note though that the rest of the code will also have to change considerably to support the timeouts. Cheers! Leo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
