如何接收子进程的输出？ STDOUT 无阻塞或极化
我有一个长期运行的基于控制台的应用程序 Sender，它使用非缓冲输出（例如 cout <<;）将简单文本发送到 STDOUT。 《留言》<<刷新（）。我想创建一个基于 MFC 对话框的应用程序（名为 Receiver），该应用程序启动 Sender 并可以读取其输出。 Receiver 还应该能够检测到 Sender 何时死亡，或者能够在需要时杀死 Sender。 Sender 对 Reciever 一无所知，而且我无法更改 Sender 的代码。
我的第一次尝试是为子进程创建带有重定向 STDIN 和 STDOUT 的管道，并使用异步 ReadFileEx 调用来读取 Sender 的数据。这无法正常工作，我已经发布了单独的关于这些具体问题的主题。
我的问题是，从一般的架构角度来看，我应该如何做到这一点？我不希望 Receiver 的主循环阻止或轮询，但应该使用某种风格的 等待函数。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您有 2 个基本选项。您已经尝试过选项 1，即执行异步（又称非阻塞）IO 来从子进程读取/写入。选项 2 是在 Receiver 进程中创建一个单独的线程，用于阻止子进程的读取/写入。
我推荐选项2，我发现它更容易。当然，你会遇到如何将数据从辅助线程获取到主线程的问题。为此，您需要使用锁，也许还需要使用信号量。然而，它应该比非阻塞 IO 少一些麻烦。
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.