Cleanly end a thread with blocked i/o in win32?

Trying to work around the lack of pexpect for native windows python I
had a play with os.popen2 and some threads. This looks promising
enough for what I want to do, but I hit on a problem with getting the
script to exit cleanly. Tried replacing popen with subprocess but I am
still confused. Either it needs to be killed from the task manager, or
I get a variety of different complaints and popping up "application
error" windows. I managed to get it to stop with os.abort(), but this
invites a complaint from windows about terminating in an unusual way.
Closing the file descriptors of the child process leads to a crash and
I think I should be sending a kill to the process, although I don't
know how (please tell me).

Would any of you care to have a look at the code below and make
suggestions for tidying it up properly? It also dies nastily if the
child process terminates. Eventually I would like to fire off a
program from a gui, supply input programmatically, depending upon the
unpredicable questions the program might ask, and prompt the user if
the child process asks something unknown. Also process the output into
a graphical form so the user can change options and run the child
again. Makes the crashing a bit of a problem! Entirely different
approaches which can accomplish this task would also be very very
welcome, I tried a telnet to localhost suggestion, but this was
painfully slow on this windows xp machine (using "services for unix"
telnet server). The communicate bit of subprocess only gives me one
chance to talk to the process. Should I be inheriting from subprocess
and editing the communicate method there?

Having googled extensively on this problem it seems that tidying up
this code could be useful to others too?

Thanks!!

Jon
---
import os,sys,time,subprocess
from threading import Thread

out = ""

class reader(Thread):
def __init__(self,file_to_read):
self.file_to_read=file_to_read
Thread.__init__(self)
def run(self):
global out
while 1:
i=self.file_to_read.read(1)
out+=i
sys.stdout.write(i) # for debugging

class writer(Thread):
def __init__(self,file_to_write):
self.file_to_write=file_to_write
Thread.__init__(self)
def run(self):
global out
while 1:
i=sys.stdin.read(1) # for debugging
out+=i
self.file_to_write.write(i)

if __name__=="__main__":
child = subprocess.Popen(sys.argv[1],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
# or: child.stdout,child.stdin = os.popen2(sys.argv[1])
r = reader(child.stdout)
w = writer(child.stdin)
r.start()
w.start()
while r.isAlive() and w.isAlive():
try:
time.sleep(10)
except:
print "\n=== in out now ===\n",out,"\n======"
break
print r.isAlive(),w.isAlive() # Who died, in or out??
time.sleep(1)
print r.isAlive(),w.isAlive() # Who died, in or out??
print "You fell off of the bottom of the script"

jo*************@gmail.com (Jon Wright) wrote in message

Trying to work around the lack of pexpect for native windows python I
had a play with os.popen2 and some threads. This looks promising
Just curiosity: why did you try using UNIX methods in win32?

I am after a particular functionality - I don't care what methods are
used; I just want to save myself repetitively typing crap into a
program and only answer the interesting questions it asks. Starting
another program and communicating programmatically via stdin and
stdout (usually defined in a language specification) is a convenience
for any multitasking os. Your suggestion helps a great deal however -
one just needed to know the translation into win32 for 'kill'. In my
case this seems sufficient:

def kill_win32(child):
import win32api, win32con
child.stdin.close() # should really check if this is open etc
handle = win32api.OpenProcess(win32con.PROCESS_TERMINATE,
0,[child.pid])
win32api.CloseHandle(handle)
child.stdout.close() # ditto
# error handling

Doubtless other children would resist this and some stronger magic
could be needed to snuff them out?

Perhaps this would be a useful thing to put into the "subprocess.py"
module which I think has now become part of the standard library...?
Probably a windows expert can do much better, and eventually lines
saying if win32 do this, if unix do that. Does that need a PEP or a
patch or is someone going to tell me why it shouldn't be there? Maybe
calling it "child.try_to_kill()" is enough to indicate that it won't
always work?
To prove that windows isn't unix?