Re: popen read and write?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: popen read and write?
- From: Duck <duck@...>
- Date: 2007年10月10日 22:26:41 +1000 (EST)
How about this implementation?
http://mysite.mweb.co.za/residents/sdonovan/popen.zip
It is prone to deadlocks.
Anything of Steve's popen2 sort is prone to deadlock, most commonly
because its most useful purpose is to allow you to "program" or to script
the remote control of an interactive program...so you'd better not make
any mistakes. (Same sort of problem you have with |& in gawk, or when
using expect, or any templated scripting of an interactive program. After
all, if you could solve this problem generically you could pass a Turing
Test with ease ;-)
[snip]
Thanks, I shall keep hammering it ;) Duck has
also noticed that one can get zombie processes
with it.
If the subprocess hangs, or you give up and close the pipes before the
process ends...
I had in mind extending Steve's code (and may yet do it) in order to:
1. Provide for "close" and "kill" methods (callable explicitly at any
time, or implicitly at __gc time) which attempt to get rid of unfinished
subprocesses -- with varying degrees of co-operation from the subprocess.
2. Provide for a "peek" method which portably allows you to see whether a
read is going to block. (On Linux I think you can simply use select(). On
see if reads on a pipe will block or not.)
(1) will allow zombies to be avoided. (2) will make parent read()s much
safer. If the wrong, or no, data comes back you will be able to bail out
after a user-specified timeout. A LuaSocket-type timeout for "total
subprocess runtime" (LuaSocket lets you have a timeout on individual
reads and on total time blocked -- nice) would be handy, but the
Linux and Windows code would be irritatingly different.
I just have to get a Round Tuit :-) Don't hold your breath.