Question on processes 'n' threads #1

[Guest]

HI,
I am using Process.RedirectStandardOutput to read the output of a console process, quite successfully. (I am basically just doing "cmd.exe /c dir *.csproj /s /b" to list out all the .csproj files), however, instead of appending >textfile.txt to the end, I can use a StreamReader to read the data. This *seems* to be working successfully, but i was wondering what would happen if the application reading the data couldn't read (and process) it as fast as the process was outputting it?

Or does it (as I'm hoping) know that if its standard output redirected flag is true, then it needs to wait for each line that it outputs to be read before it can continue? I was hoping somebody could confirm this behaviour or tell me what it really is.
Thanks!

 

[Nicholas Paldino [.NET/C# MVP]]

Beeeeeeeeeeeeves,

This can't happen. The process will output whatever it is going to do,
but when your StreamReader accesses it, it will be buffered until that line
is read from the buffer. You don't need to worry about the application
outputting information faster than you can process it.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

HI,
I am using Process.RedirectStandardOutput to read the output of a console

process, quite successfully. (I am basically just doing "cmd.exe /c dir
*.csproj /s /b" to list out all the .csproj files), however, instead of
appending >textfile.txt to the end, I can use a StreamReader to read the
data. This *seems* to be working successfully, but i was wondering what
would happen if the application reading the data couldn't read (and process)
it as fast as the process was outputting it?

Or does it (as I'm hoping) know that if its standard output redirected

flag is true, then it needs to wait for each line that it outputs to be read
before it can continue? I was hoping somebody could confirm this behaviour
or tell me what it really is.

 

[Guest]

This can't happen.

I thought so.

The process will output whatever it is going to do,
but when your StreamReader accesses it, it will be buffered until that line
is read from the buffer.

OK, 'buffering' - so, I am imagining the StreamReader object storing up more and more lines in its memory waiting for me to retrieve them if the process is running faster than my program is reading it, so these lines will just be read as and when my program gets round to it.

You don't need to worry about the application
outputting information faster than you can process it.

OK, I understand how it buffers it. But what if it happens the other way round? What if my application tries to read the information faster than the process can output it? Will it simply block until it *does* output something (and return null if it ends)?

What I'm currently doing is something like
using(Process p = new Process()) {
//.....starting the process...
String s;
while((s = p.StandardOutput.ReadLine()) != null) ProcessData(s);
//....I'm assuming the process has now finished its work and exited of its own accord.
//.. I don't need its return value or anything, but I do need to make sure it's allowed to finish of its own accord...

} //(end using)

and I'm *ASSUMING* that when the result of the assignment to the string s is null, then the fact that the process has no more data left to output means that it has finished.

IS this assumption valid, or should I use something different??? i.e. would anything else cause the result of StandardOutput.ReadLine() to be null apart from the process ending?

 

[Nicholas Paldino [.NET/C# MVP]]

Beeeeeeeeeeeeves,

Yes, your application will block until it receives more input.

And your assumption is valid. The ReadLine method should return null if
there is nothing left to read from the stream.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I thought so.


OK, 'buffering' - so, I am imagining the StreamReader object storing up

more and more lines in its memory waiting for me to retrieve them if the
process is running faster than my program is reading it, so these lines will
just be read as and when my program gets round to it.

OK, I understand how it buffers it. But what if it happens the other way

round? What if my application tries to read the information faster than the
process can output it? Will it simply block until it *does* output something
(and return null if it ends)?

What I'm currently doing is something like
using(Process p = new Process()) {
//.....starting the process...
String s;
while((s = p.StandardOutput.ReadLine()) != null) ProcessData(s);
//....I'm assuming the process has now finished its work and exited of its own accord.
//.. I don't need its return value or anything, but I do need to make sure

it's allowed to finish of its own accord...

} //(end using)

and I'm *ASSUMING* that when the result of the assignment to the string s

is null, then the fact that the process has no more data left to output
means that it has finished.

IS this assumption valid, or should I use something different??? i.e.

would anything else cause the result of StandardOutput.ReadLine() to be null
apart from the process ending?

 

[Beeeeeves]

right, excellent. thanks

Beeeeeeeeeeeeves,

Yes, your application will block until it receives more input.

And your assumption is valid. The ReadLine method should return null if
there is nothing left to read from the stream.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I thought so.


OK, 'buffering' - so, I am imagining the StreamReader object storing up

more and more lines in its memory waiting for me to retrieve them if the
process is running faster than my program is reading it, so these lines will
just be read as and when my program gets round to it.

OK, I understand how it buffers it. But what if it happens the other way

round? What if my application tries to read the information faster than the
process can output it? Will it simply block until it *does* output something
(and return null if it ends)?

What I'm currently doing is something like
using(Process p = new Process()) {
//.....starting the process...
String s;
while((s = p.StandardOutput.ReadLine()) != null) ProcessData(s);
//....I'm assuming the process has now finished its work and exited of

its
own accord.

//.. I don't need its return value or anything, but I do need to make

sure
it's allowed to finish of its own accord...

} //(end using)

and I'm *ASSUMING* that when the result of the assignment to the string

s
is null, then the fact that the process has no more data left to output
means that it has finished.

IS this assumption valid, or should I use something different??? i.e.

would anything else cause the result of StandardOutput.ReadLine() to be null
apart from the process ending?