I am writing two applications - one (let's call it application A) is a C# Winforms UI and the other (application B) is a C# console application. I am using stdin/stdout to pass commands and responses between program A and program B. This is working fine. However, application B spawns two subprocesses (B1 and B2), and I would like to pass the stdout streams of B1 and B2 back up to application A so that they can be displayed to the user as 'debug' information if desired. I want to keep this debug outout segregated from the stdout stream which contains application B's machine-parseable responses to application A.
Is there a way that I can create two additional output streams (similar to stdout) from application B, such that application A can read them? I realise I can use files for this, however I'd like to avoid writing to disk if I can. I know that under the hood, stdout and stderr are 'file descriptors' 1 and 2 respectively, which can be redirected anywhere on the command line using '>' and '2>'. Essentially what I'm trying to do is create additional streams 3 and 4 which behave the same way.
I've also been reading about using anonymous/named pipes for this, but am I correct in saying that read/write calls to pipes are blocking if the pipe is empty/full, or if no consumer has connected to the other end of the pipe? This is not what I want - if nothing reads from these debug streams then I don't want application B to lock up, just as a console application would continue running even if nothing is consuming its stdout. Using pipes would presumably also prevent me from using the command line to redirect these two additional streams 3 and 4 into files whilst debugging application B, which would be a nice bonus feature.
Comments
Post a Comment