StandardError was commented out, to avoid that exact scenario.
Jon
"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
news
p.tqb4yrsb8jd0ej@petes-computer.local...
> On Thu, 05 Apr 2007 13:24:44 -0700, Jon Davis
> <jon@REMOVE.ME.PLEASE.jondavis.net> wrote:
>
>> Clearly it is deadlocking, the problem is I don't know how to apply any
>> workaround to the code I provided in the OP given the samples provided in
>> the referenced link, which although appears detailed at first glance is
>> really too brief to be useful.
>>
>> Perhaps someone has the time and patience to make my two samples work? 
>
> Most of us probably don't have the associated programs you're running
> installed. I know I don't.
>
> That said, reading the documentation it occurs to me that you may be
> running into a problem with your processing of the StandardError stream.
> That is, I don't see anything in your code that would read from that
> stream. According to the documentation, if your own application does not
> keep up with reading data from the streams, the child process may block
> once the stream's buffer is full. That would prevent your child process
> from continuing, while your parent process sits there waiting to read more
> from the other stream.
>
> If you are going to redirect both StandardError and StandardOutput, it
> seems to me that the only robust way to do that is to ensure that both
> streams are being read from simultaneously. You can do that by providing
> for asychronous reading of at least one of them (ie BeginOutputReadLine
> and/or BeginErrorReadLine). That way, you can ensure that you will always
> be reading from both and not preventing the child process from
> continuing. Alternatively, use two different threads to read from the two
> streams.
>
> Both of these techniques are documented near the end of the "Remarks"
> section for the RedirectStandardOutput property in MSDN (the link you say
> is "too brief to be useful").
>
> Pete