Stefan Bodewig wrote:
On Mon, 14 Oct 2002, <[EMAIL PROTECTED]> wrote:This is reasonable and I'm happy to discuss this with whoever may be interested. I could quite easily be wrong, and I would hate to commit a fix which introduced a new problem for someone else.
Hmm,Hmm, but if you read from stdin, you'll block until something is
available to read, so this shouldn't be a problem, right?
this here (from the javadocs of java.lang.Process)
,----
| The created subprocess does not have its own terminal or console. All
| its standard io (i.e. stdin, stdout, stderr) operations will be
| redirected to the parent process through three streams
| (Process.getOutputStream(), Process.getInputStream(),
| Process.getErrorStream()). The parent process uses these streams to
| feed input to and get output from the subprocess. Because some native
| platforms only provide limited buffer size for standard input and
| output streams, failure to promptly write the input stream or read the
| output stream of the subprocess may cause the subprocess to block, and
| even deadlock.
`----
is the stuff that worries me (and that your patch may or may not
trigger). The current code seems to run into the "failure to promptly
read the output stream" on your setup, I don't want to replace it with
code that runs into the other case in other environments.
With all due respect, I don't see what all the fuss is about."all this fuss" is about a committer who remembers he applied a patch
to Cab.java a while ago and worked with the one who submitted the
patch because an initial version had problems with the stuff above.
I can't test the task myself, neither can any other committer (it
seems), so I prefer to at least be comfortable with what I commit, and
this may involve some discussion.
The old behavior:
1) main thread writes entire input into process's stdin
2) main thread spawns two threads to read stdout, stderr (async)
3) main thread waits for process to complete
Obviously the first step can block if the process stops reading stdin and the stdin buffer becomes full. The process could possibly stop reading stdin if it blocks writing stdout or stderr (which are not being flushed during step 1).
The modified behavior:
1) main thread spawns two threads to read stdout, stderr (async)
2) main thread writes entire input into process's stdin
3) main thread waits for process to complete
Since we have three threads servicing the process' three streams simultaneously, we shouldn't have the potential problem described in the javadoc.
Jim
--
To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>
