Re: problems getting stderr and stdout from process object
Tom Anderson wrote:
On Mon, 28 Sep 2009, Daniel Pitts wrote:
Peter Duniho wrote:
On Thu, 24 Sep 2009 11:52:19 -0700, Daniel Pitts
The problem I have isn't with the blocking-on-buffer-fill behavior,
but with the fact that you *must* have two threads running to use this
API successfully.
I can think of three alternatives off the top of my head:
1. Don't use two InputStream instances, but instead use a new kind of
IO class designed to handle interleaved data. It would allow better
correlation between events in each "stream", and it would allow you to
read the streams in the current thread, without spawning a new one.
Does available() work on the stdout from a child process? If so, i think
you could implement single-thread interleaved (or at least
interleaveish) IO on top of the current API.
2. Offer some sort of "select()" based waiting for the streams. This
allows one thread to handle multiple streams.
This would be really useful.
3. 1 and 2 combined.
What would also be useful would be a way to redirect the child's input
or output from or to a file (or /dev/null or its equivalent). You could
then run a process, feed it input, wait for it to finish, then read the
output file. Only one thread needed, and no IO weirdness.
That could be additional functionality that might be useful, although it
can currently be achieved multiple ways. Though you'd still have to deal
with IO, which is the ultimate weirdness in CS theory :-)
It would be important for the select() to also support "OutputStream"
readiness, because you could otherwise end up with a deadlock (the
process is supposed to receive more input, but the output buffer is
full, so the whole thing might block)
[snip]
Creating one thread is more than just run-time overhead. There is a
development cost with multi-threading. You are more prone to
deadlocks, synchronization problems, and much more, when you create a
new Thread. Yes, those problems can be avoided, but its *much* more to
think about.
If all your thread is doing is pumping data into the child process,
there is nothing more to think about. The above paragraph looks mostly
like FUD to me - no offence, i just think this is a manifestation of the
superstitious fear of threads that is commonplace in the java world.
tom
Actually, in this case, the extra thread is pumping the data *out of*
the external process, into the current JVM. The implementation isn't
actually that hard to get correct. I might have given into hyperbole,
but I have seen many incorrect attempts, and only a few correct ones.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>