On Sat, Nov 27, 2010 at 10:07:54AM -0500, Schwab,Wilhelm K wrote:
Yes, there is definitely a time for using #close rather than #closePipes.
In the context of a PipeableOSProcess, #close means "I am done writing
things to you". That means that the external process will see EOF on its
input, and presumably will complete its processing and write some additional
output. You do not want to do a #closePipes at this point, because that
will make it impossible to read that last output from the external process.
I left the responsibility for calling #closePipes with the user of the
PipeableOSProcess, who will presumably read data up to end of file and
then close the pipes when done.
You're right, it's a recurring trap for casual users. It's also an
inherently asynchronous operation, and I don't know an easy way to
make it right for all use cases. To some extent it depends on how
you intend to use it; if the external process is a /bin/ls command,
then you probably would want to run the program, close the input, read
all output up to end of file, then close all pipes. On the other hand,
if the external process is /usr/bin/wish (a Tk/Tcl interpreter), then
you want to just run the program and keep all pipes open until you
are done interacting with the external interpreter.
> It appears that I had been having intermittent problems with this for
> a while. Yesterday, I ran a big batch that would not go to completion,
> and I noted that after the first error, pretty much every file operation
> failed. The latter lead me to strongly suspect cleanup of the pipes,
> and the above was then easy to find. The batch runs nicely now.
Good!
Dave
Locked
