Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.
Standard Input, Output, and Error Streams
I have two ongoing questions that I can't seem to figure out. I'm about to start learning C/C++ so I can skip the .NET framework's black-box.
First, I have made an application (we'll call it the parent) that wraps around a command-line application (lets call this the child). When the parent starts up the child process it redirects the standard input, output, and error streams to the parent process. The parent process can then act like it's a user using the command-line application, and interact with it accordingly.
I have made the application and it works flawlessly with a command-line (console type) project in VB.NET. However, when I try to wrap around a command-line application that was not written in .NET it seems that none of the output data shows up in the standard output stream that is made available by the .NET Process class. Which brings me to my actual question. Is it possible that the command-line assemblies written in non-dotNet architecture are using a standard output stream that is not recognized by the .NET architecture? (From what I know so far, this would not be true. Trying to validate these beliefs so I can move on.)
The second question I have is this. How can a StreamReader block on a Peek() call? The .NET documentation does not even hint that this is possible. In fact it would seem that the purpose of Peek() is to check to see if the stream is empty or what not. However I keep having the thread block as soon as it passes into the StreamReader.Peek() method.
I had a theory that it would block if the stream it was trying to read was empty and had not had any data written to it, but I proved this theory wrong by creating a Stream instance and then trying to read from it without writing anything to it. In my test case, the Peek() method return -1 and ran without a hitch. Exactly what is expected according to the documentation.
My question then is this. What kind of scenarios could possible make a StreamReader.Peek() method call block? I am using multiple threads in my application so dead-lock is a possibility, although I only have a reference to the StandardError stream in one place so I wouldn't think that there is any sharing of resources across the threads that are created inside my application.
0 · ·