 |
lua-l archive |
|
|
||
|
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.