I have a long-running console-based application Sender that sends simple text to STDOUT using non-buffered output such as cout << "Message" << flush(). I want to create an MFC dialog-based application (named Receiver) that starts Sender and can read it’s output. Receiver should also be able to detect when Sender has died, or be able to kill Sender if it wants to. Sender knows nothing of Reciever, and I can’t change Sender‘s code.
My first attempt was to create pipes with redirected STDIN and STDOUT for the child process and use asynchronous ReadFileEx calls to read in Sender‘s data. This isn’t working correctly, and I’ve posted a separate thread about those specific problems.
My question is, how should I be doing this, in general architectural terms? I don’t want Receiver‘s main loop to block or poll, but should use some flavor of Wait function.
You have 2 basic options. Option 1 you’ve already tried, doing asynchronous (aka nonblocking) IO to read/write from the child process. Option 2 is to create a separate thread in the Receiver process that does blocking reads/writes from/to the child process.
I’d recommend option 2, I find it much easier. You then, of course, have the problem of how to get the data from the helper thread to the main thread. You’ll need to use locks and maybe semaphores for that. It should be less of a hassle than nonblocking IO, however.