Re: problems getting stderr and stdout from process object
Daniel Pitts wrote:
[...]
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.
Since the external process may buffer the two streams independently
and may flush the buffers at times dictated by ungovernable whim, the
task of correlation (which I presume means establishing that "X was
written to stdout before/after Y was written to stderr") doesn't seem
to be significantly eased.
2. Offer some sort of "select()" based waiting for the streams. This
allows one thread to handle multiple streams.
Yes, except that using a thread is easier. If you had dozens or
hundreds or thousands of streams to monitor, that'd be another matter --
but if you're controlling that many simultaneous external processes,
you're probably going to be using "outside the box" rather than "out
of the box" approaches anyhow.
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.
YMMV, but a Thread that just sucks up a stdout or stderr stream
independently of the other Thread doesn't seem "*much* more" complex.
If anything, it seems simpler than an event-triggered mechanism that
handles two (three? N?) streams simultaneously. You wind up writing
"inverted control structures" and spreading the program's decision-
making across umpty-leven nodes of a state machine.
Of course, a lot depends on how much "structure" the streams
have. If it's just line-at-a-time-and-all-lines-are-independent,
then neither approach is all that complicated.
--
Eric.Sosman@sun.com