问题标签 [boost-process]

我正在使用 boost::process 调用外部程序 - 外部程序通过 stdin 读取输入，并写入 stdout 和 stderr。外部程序如下（需要一个参数 - 用于调试的文件的路径）

调用者需要 2+ 个参数，其中一个是外部程序的路径，其余的作为参数传递给外部程序。

它在等待进程退出时挂起，看起来外部程序正在等待来自标准输入的 EOF。

我的印象是，将我的标准输入管道和相关的源/接收器放在一个范围内将保证它们是关闭的，因此会发送 EOF。

相同的代码在 Windows 下完美运行（VS2013，boost_1_53）。

我正在使用 boost_1_53、boost-process 0.5、gcc 4.8.2。

我对这个链接错误有点迷茫，我认为问题出在我这边而不是在库本身，但我不知道如何解决这个问题。

我正在尝试链接到 boost::process 0.6 https://github.com/klemens-morgenstern/boost-process/

主文件

记录器.cpp

录音机.h

我有两个线程，每个线程启动一个子进程。第一个应用程序是一个运行时间很长的二进制文件。第二个退出很快。

有一个竞争条件有时会导致失败。下面我有一个最小的可行代码示例。

它使用 Boost Process 0.5，它使用标准的 fork / execve / dup2 系统。关于 Boost Process 的工作原理有一些技巧，但总的来说它工作得很好。

父进程启动了更多进程，并且通常可以正常工作。

我不能一次轻松地启动一个进程，特别是因为我不知道哪些部分不能交错。

关于为什么会挂起的任何想法？

预期输出：

但是，它经常（但并非总是）在 std_err_pipe 处停止。

（另存为 process-test.cpp 并用 编译g++ process-test.cpp -o process-test -lboost_iostreams -lboost_filesystem -lboost_thread -lboost_system）

我正在尝试使用 Boost-1.64.0 调用带有字符串到其标准输入的进程。当前代码是：

问题是子可执行文件正在等待其标准输入 EOF。这里 child.wait() 无限期地挂起......

我尝试使用 asio::buffer、std_in.close()、……但没有运气。我发现的唯一 hack 是 delete() inStream ......这并不可靠。

我应该如何“通知”子进程并使用新的 boost::process 库关闭其标准输入？

谢谢 ！

我在文档页面上看到了以下代码boost::child，它们解释了如何读取子进程的输出。 http://www.boost.org/doc/libs/1_64_0/doc/html/boost_process/tutorial.html 他们说运行你的子进程后，我们可以通过这个循环阅读它：-

我在这里有两个问题：-

1. 如果c.running()返回 false，我们只需退出循环。在那种情况下，is上面的流可能仍然携带丢失的数据？
2. 什么是同时读取 stdout 和 stderr 的最佳方法，同时确保进程 exit() 不会创建死锁 页面上有一条警告说：-
   如果您在 nm 退出后尝试读取，管道将导致死锁

我希望同时捕获两者stdout，stderr而不必担心nm已经退出或不在上面。

我想从我的应用程序中生成一个子进程，这样它们的生命周期就会绑定，即当我的应用程序关闭时，子进程也关闭。为了达到同样的效果，我使用了boost::process::child::terminate().

使用的问题terminate()是生成的子进程不知道它正在退出，因此无法采取必要的步骤来确保退出是干净的（关闭打开的文件句柄、释放资源等）。

在不使用进程间通信的情况下，有没有办法在子进程中检测到它正在被终止或以某种方式与子进程通信？

我尝试使用以下处理程序在子端捕获终止，但没有任何成功：

有什么想法吗？

我正在Boost::Process玩弄（1.64.0），使用 GCC 7.1.1，试图vfork()在分叉进程时强制使用。我收到以下程序的链接器错误：

使用：

生成的链接器错误如下

在函数'boost::process::detail::posix::executor>, boost::fusion::filter_view&, boost::process::detail::posix::use_vfork_ const&> const, boost::process::detail ::is_initializer > > > >::operator()()': spawn_simple.cpp:(.text._ZN5boost7process6detail5posix8executorINS_6fusion10joint_viewINS4_5tupleIJNS2_12exe_cmd_initIcEEEEENS4_11filter_viewIKNS6_IJRA6_KcRNS2_8null_outILi1ELin1EEERKNS2_10use_vfork_EEEENS1_14is_initializerIN4mpl_3argILin1EEEEEEEEEEclEv[_ZN5boost7process6detail5posix8executorINS_6fusion10joint_viewINS4_5tupleIJNS2_12exe_cmd_initIcEEEEENS4_11filter_viewIKNS6_IJRA6_KcRNS2_8null_outILi1ELin1EEERKNS2_10use_vfork_EEEENS1_14is_initializerIN4mpl_3argILin1EEEEEEEEEEclEv]+0x31): undefined reference to `boost::process::detail::posix::executor > , boost::fusion::filter_view&, boost::process::detail::posix::use_vfork_ const&> const, boost::process::detail::is_initializer > > > >::invoke(mpl_::bool_, mpl_::bool_)'

据我所知，Boost Process 本身只是标题，那么为什么它抱怨未定义的引用boost::process<...>::invoke()？

我尝试添加-lboost_systemand -lboost_iostreams，但这并不能解决链接器错误。

根据Boost 文档（“为什么管道不关闭？”部分），以下代码将导致死锁：

文档说：

这也会死锁，因为子进程退出时管道不会关闭。因此，即使进程结束，ipstream 仍会查找数据。

但是，我无法重现死锁（在 Linux 下）。此外，我不明白为什么会首先发生死锁。一旦子进程退出，它就会关闭管道的写端。管道的读取端仍然可供父进程读取，并且std::getline()一旦管道缓冲区中没有更多数据可用并且写入端关闭，它就会失败，对吗？如果在子进程执行期间管道缓冲区填满，子进程将阻塞等待父进程从管道中读取足够的数据，以便它可以继续。

那么万一上面的代码会死锁，有没有简单的方法可以重现死锁场景呢？

更新：

事实上，下面这段代码使用 Boost 进程死锁：

我想知道这是否真的是 Linux 下进程生成的一些不可避免的属性。使用Facebook 的Folly库中的Subprocess复制上述示例至少不会死锁：

我正在尝试将 boost 库导入到我的 C++ 项目中，由于某种原因它找不到 Boost.Process，尽管它找到了其他库。

我的 CMakeLists.txt 文件：

错误的完整跟踪（带有调试设置）：

我知道 Boost.Process 仅包含在 Boost 1.64 及更高版本中，但根据输出我使用的是 Boost 1.64 和 Cmake 3.9。我查看了 /usr/local/include/boost 并且 process.hpp 在那里。

感谢您的任何建议。

我正在用 C++ 在 Raspberry Pi/Raspbian 上编写应用程序。我创建了一个命名管道（FIFO），mkfifo()然后我启动raspiyuv从我的相机中获取图像。对于内存，raspiyuv是 Raspberry Pi 命令行应用程序，它获取静止图像并将它们保存为 YUV 文件。

我正在使用 g++ 6.3 和 Boost 1.64 和-std=c++17。我创建的 FIFO 是正确的，因为我可以从命令行使用它。它按预期工作。

错误是我生成的应用程序raspiyuv立即返回退出代码 0。

我的代码：

$ raspiyuv -w 2592 -h 1944 -o - -t 0 -y -s当我直接将它输入到命令行时，该命令是正确的。此外，到 FIFO 的重定向工作正常。-w 2592 -h 1944给出抓取图像的大小，-o -表示将图像输出到标准输出，-t 0表示永远等待，-y表示仅保存 Y 通道，-s表示等待 SIGUSR1 触发图像捕获。

当我从命令行调用它时，应用程序处于空闲状态，直到我发送 SIGUSR1 然后它捕获图像并将其流式传输到 FIFO，然后返回空闲状态。没关系。

当我通过创建boost::process::child对象来生成它时，它会立即返回。

boost::process::child只要我的应用程序（父进程）还活着并且我不发送 SIGKILL 等，任何想法来纠正这个问题并允许它保持活跃？

谢谢你的帮助！