ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From news...@hotu.com
Subject Re: create cab in linux; patch request
Date Thu, 17 Oct 2002 20:42:23 GMT
Stefan Bodewig wrote:

>On Mon, 14 Oct 2002, <newsham@hotu.com> wrote:
>
>  
>
>>>>Hmm, but if you read from stdin, you'll block until something is
>>>>available to read, so this shouldn't be a problem, right?
>>>>        
>>>>
>
>Hmm,
>
>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.
>  
>

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.

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>


Mime
View raw message