Hello NG,
Thanks. I have solved the problem by using the win32api library:
def kill_pid(pid):
if sys.platform == sys.platform:
import win32api, win32con
handle = win32api.OpenProcess(win32con.PROCESS_TERMINATE, 0, pid)
win32api.TerminateProcess(handle, 0)
win32api.CloseHandle(handle)
else:
os.kill(pid, signal.SIGTERM)It works! Maybe there are other good ideas.
That is very weird, as that is almost the same thing that the C++
wx.Kill does when the wx.SIGKILL is used. It just adds some additional
flags to the OpenProcess call.
I had to do something similar. My wxPython application starts an external
exe that connects via rsh to a Unix machine for a *really* long-running
task.
The problem with the wxPython wx.Process arises when my PC "looses" for
a while the rsh connection to the Unix machine (soon re-estabilished by
our servers): I get a Windows error saying something like "Python has performed
some illegal operation and will be shut down. Do you want to send the error
report to Microsoft etc... etc..."
So, I decided to implement a "launch & forget" process like:
self.process = os.spawnl(os.P_NOWAIT, command)
and I monitor the intermediate output repeatedly using a wx.Timer. Then,
if something really weird happen (simulation in error, or the user decides
to kill it), I just do:
win32process.TerminateProcess(self.process,-1)
I don't even know why wx.Process does such "Windows-Segmentation-Fault"
(or is it a core dump the exact equivalent? 
), but I am sure that it
would not be easy to reproduce on a simple app...
Andrea.