[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] run_tests.py subprocess mode and Build Page extensions

I'm not sure... but if it works without we can cut it huh? I was under the impression that unless you ran a shell as intermediary you had to use absolute paths for everything....(I thought that using shell would provide the env) but it seems I was on crack. 

>> And if anything hangs it can still be killed by Process Viewer.
I was more thinking more for the automated build page, where a "client" could be left for days without supervision.
A single process os.kill using TerminateProcess would then work if there was no intermediary shell huh? If shell = 0 it won't start the (shell) cmd.exe or command.com etc first? 

......
OK, I just tried and indeed it thats what happens using shell=0. I used process explorer and run_tests.py only creates python.exe children. No process tree == win98 happiness. 

.....
I removed the taskkill, pskill os.kill() hack and replaced it with a method on the async Popen object. If not windows, it uses os.kill() 

if subprocess.mswindows:
   def kill(self):
       """kill function for Win32"""
       handle = win32api.OpenProcess(1, 0, self.pid)
       return (0 != win32api.TerminateProcess(handle, 0))

So, we should now be good for win98+ and *nix ?

Thanks for your help Lenard.

Lenard Lindstrom wrote:
This is not a big issue. I don't think there is anything like a process tree in Windows 98. And if anything hangs it can still be killed by Process Viewer. The timeout works, so that is all that really matters. Just out of curiosity though, why use a shell as an intermediary. Why isn't the Python interpreter executed directly in the subprocess? 

>>> cmd = 'python -c "print \\"Hello.\\""'
>>> print cmd
python -c "print \"Hello.\""
>>> import subprocess
>>> out = open('C:/windows/desktop/stdout.txt', 'w')
>>> s = subprocess.Popen(cmd, stdout=out)
>>> s.wait()
0
>>> out.close()
>>> print open('C:/windows/desktop/stdout.txt').read()
Hello.


Lenard


Nicholas Dudfield wrote:

Lenard,

Weird, XP?  Vista?   I'm on XP SP3
By passing an env = {} to the Popen constructor temporarily to remove PATH from the environment it fails my end. 

D:\Nick\PyGame\trunk>run_tests.py -s
No way of killing unruly processes. Try installing sysinternals pskill and placi 
ng on %PATH%.
I found a recipe for TerminateProcess, but it didn't kill child processes so it would stop the run_tests from hanging but on mine at least, python would call cmd which would in turn call python. It would only kill cmd.exe, leaving python to run rampant. 

cmd
   python                        run_tests.py
cmd python xxxx_test.py
But yeah, we really need it to be consistent however it works. It would be nice if it would kill process trees also. 

You are more than welcome to make any changes.

To run a test_suite with a test that "while True: pass"
$  run_tests.py -s -f infinite_loop

I have been meaning to add that to the run_tests test.

Cheers


Lenard Lindstrom wrote:

Hi,
I tried running the tests in subprocess mode an everything passed. Great, except I didn't have either pskill or taskkill installed. When checking for the programs Popen.wait() always returned 0, even when the program was not found. So it incorrectly assumed I had pskill installed (first in the list). Anyway, since pywin32 is already required, why not do the TerminateProcess system call directly, making pskill or taskkill unnecessary. If interested I can making the necessary changes to async_sub.py. 

Lenard