Reading StandardOutput from a Process (no deadlock please)

[bob_jeffcoat]

Hi,

I'm trying to read the output and write the input of a process using
its StandardOutput/Input and I'd really like to check if the process
is waiting for input or whether it has output ready to be read. Is it
possible? It seems like a fairly simple thing to try and do but most
of the "read" functions I've tried seem to deadlock if there's nothing
to read due the process waiting for output. It's rubbish!

Even a simple "try for 100millieseconds and give up" would be ok, but
I can't see how to do that either.


any ideas?

Thanks

 

[Guest]

Not sure how you are doing your I/O but iostream and streamreader have Peek
methods. Hope this helps.

 

[UL-Tomten]

I'd really like to check if the process is waiting for input

I don't think this is possible. Are you sure you need it?

or whether it has output ready to be read.

See tbain's Peek() response.

deadlock

Technically, what you're describing is a "blocking read". Deadlocks
are (by definition) permanent.

 

[bob_jeffcoat]

I don't think this is possible. Are you sure you need it?


See tbain's Peek() response.


Technically, what you're describing is a "blocking read". Deadlocks
are (by definition) permanent.

Thanks for the responses.

I had a go with Peek(), but it's not great as sometimes it answers -1
but you can still do a successful ReadLine(). Think it may be
answering -1 for an empty line.

It's quite annoying.

Oh well, thanks anyway

 

[UL-Tomten]

I had a go with Peek(), but it's not great as sometimes it answers -1
but you can still do a successful ReadLine(). Think it may be
answering -1 for an empty line.

I have a feeling you didn't bother to read the documentation for
either the Peek() method or the ReadLine() method. I hope that
approach works out for you.

 

[bob_jeffcoat]

I have a feeling you didn't bother to read the documentation for
either the Peek() method or the ReadLine() method. I hope that
approach works out for you.

You are right, of course - I never read the documentation. But now
I've read it it doesn't seem to have helped. My problem was that a
Peek may answer -1, but then a ReadLine will answer a line. This does
not agree with the documentation which states that Peek can be used to
determine end of stream by checking for -1. Perhaps this is why I
don't read the documentation.

You seem to suggest that you have an explanation, do you?

Thanks,

 

[UL-Tomten]

You are right, of course - I never read the documentation. But now
I've read it it doesn't seem to have helped. My problem was that a
Peek may answer -1, but then a ReadLine will answer a line. This does
not agree with the documentation which states that Peek can be used to
determine end of stream by checking for -1. Perhaps this is why I
don't read the documentation.

Well, I can agree that the MSDN documentation is flaky sometimes, and
the fact that intimately related bits of content are split across many
pages is also annoying, but the "Remarks" section on the main page of
a class usually contains useful hands-on information. Reading the
documentation also helps you phrase questions in a more precise way,
and is generally considered courteous before posting in a newsgroup.
But don't take my word for it.

ReadLine() will always return a line eventually, and hence is in no
hurry to complete. Its friend Peek(), on the other hand, will return
-1 if it doesn't believe Read() can return something immediately (you
haven't mentioned which class you're ReadLine()ing on, but I don't
think there's any relation between Peek() and ReadLine(); only between
Peek() and Read()).

Why do you need to rely on Peek()? What are you doing while waiting
for the standard output of the started process to return a line? What
is your reason for wanting to go with the "try to ReadLine() for
100ms, then give up" scenario? Perhaps a multi-threaded consumer-
producer would be a more robust solution to your problems? <http://
zone.ni.com/devzone/cda/tut/p/id/3023>

 

[bob_jeffcoat]

Well, I can agree that the MSDN documentation is flaky sometimes, and
the fact that intimately related bits of content are split across many
pages is also annoying, but the "Remarks" section on the main page of
a class usually contains useful hands-on information. Reading the
documentation also helps you phrase questions in a more precise way,
and is generally considered courteous before posting in a newsgroup.
But don't take my word for it.

ReadLine() will always return a line eventually, and hence is in no
hurry to complete. Its friend Peek(), on the other hand, will return
-1 if it doesn't believe Read() can return something immediately (you
haven't mentioned which class you're ReadLine()ing on, but I don't
think there's any relation between Peek() and ReadLine(); only between
Peek() and Read()).

Why do you need to rely on Peek()? What are you doing while waiting
for the standard output of the started process to return a line? What
is your reason for wanting to go with the "try to ReadLine() for
100ms, then give up" scenario? Perhaps a multi-threaded consumer-
producer would be a more robust solution to your problems? <http://
zone.ni.com/devzone/cda/tut/p/id/3023>

Thanks for your patience.

It turned out the main problem was the stupid 16bit (yes, a full 16)
app I was trying to call. I recompiled the fortran using a newer
compiler and it started to behave itself. Not sure what it was doing
though.

Thanks for you help