I've coding 'timeout' into Python Gump (allowing GumpEnvironment to detect it & register it, and allowing launcher.py:executeIntoResult to use it if found) as an optional dependency. [I've done this in the hope of helping Hermes, which (I assume) is still in an uncomfortable situation of having a rogue child.]
Right now this is a tad ugly, the code is setting a variable on a singleton (global static) from an instance object, GumpEnv. I think GumpEnv needs to be moved to a more central point, and just referenced by the Run, but not today, let's see where this takes us. BTW: If timeout is available we no longer use the pgrep/kill background thread. I was tempted to try both, but I was realized this mechanism could fight the other & kill timeout before it could kill the child. I realized I needed to go read the source code to satisfy my curiosity on how even a C program could kill children/grandchildren/etc (and if it could do it without race condition). It doesn't seem to (from my code read). Oh well, since timeout is run within the shell (we use system() 'cos no alternatives seemed to fit, at the time) it (at least) kills the first child, which is better than killing the shell. I'll ensure this runs on gump.try. What is the state of Hermes? Is this a good place to test it? regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
