问题标签 [boost-process]

我正在尝试编写一个从给定 PID 路径返回到其二进制文件或可执行文件的例程，具体取决于平台。我知道可以使用 windows.h 在 Windows 上完成，但这是依赖于平台的解决方案。

我试图使用 Qt 找到解决方案，但我离目标很远，因为无法使用提供的 PID 构造 QProcess 或任何其他类。

但是 boost(v1.66) 有一个类 boost::process::child，它可以使用提供的 PID 构造，甚至可以返回原生句柄 (boost::process::child::native_handle_t)。但从那里我不知道。

它没有任何方法（这并不奇怪，因为它似乎是 void* 的别名），但我也找不到从这个“类”中提取任何信息的任何方法。

那么有没有办法使用boost从给定的PID中提取有关二进制位置的信息，或者没有？

函数草稿：

需要为 on_exit 事件设置句柄函数。

像在 boost 教程中一样尝试分配。

g++ test.cpp -o 测试 -lboost_thread -lboost_system -pthread

使用 Windows API，我们可以使用管道来转发进程输出和错误流，因此我们可以在没有任何临时文件的情况下读取进程输出。而不是这个：

我们可以更快地工作并且没有风险地生成大量被遗忘的临时文件（例如在系统崩溃时）。

Linux 也有类似的功能。但是，为每个操作系统实现特定于操作系统的代码是一项耗时且复杂的任务，因此使用一些可移植的解决方案似乎是个好主意。

boost::process声称是这样的解决方案。但是，它基本上是不可靠的。请参阅以下示例程序：

这段代码很好用；它运行 ADB，生成 Android 设备屏幕截图并使用异步管道保存，因此不涉及临时文件。这个具体的例子将屏幕截图保存为文件，但在实际应用中，您可以将数据保存在内存中，加载并解析它。

我在我的示例中使用了 ADB，因为这个工具提供了一个很好的示例，这些数据生成速度相对较慢，并且通过 USB 或 Wi-Fi 发送（速度也很慢），并且数据大小相对较大（对于具有复杂图像的全高清设备PNG文件将是1M+）。

当我取消注释以下行时：

管道读取操作变得完全不可靠。该程序仅读取部分数据（大小不可预测）。

因此，即使是 50 毫秒这样短暂的延迟也会迫使异步管道的实施失败。

这不是正常情况。如果 CPU 使用率接近 100%（即我们在高负载服务器上）怎么办？如果线程运行可能在 50 毫秒或更短时间内执行的其他 ASIO 作业怎么办？因此，这只是基本 boost ASIO 错误的可轻松重现的实现：异步管道在您开始阅读时不能容忍任何延迟；您必须在收到数据后立即再次致电async_read，否则您有丢失数据的风险。

在实践中，当我使用相同的 ASIO 上下文运行多个作业（不仅仅是async_read读取进程标准输出的作业）时，async_pipe在 50% 的读取 1M 或更多数据的尝试中失败。

如果 ASIO 上下文运行时运行其他作业所需的延迟非常小，有谁知道如何建立async_pipe可靠而不中断连接的解决方法？async_read

当子进程由于分段违规或除为零或任何其他终止信号而被终止时，我正在尝试获取子进程的退出代码（使用 boost::process 和 boost::asio）。退出代码和错误代码始终返回 0 并成功。

我在 CentOS 7 上使用 g++ 4.8.5 和 boost 1.66 运行它

如果我使用仅返回非零退出代码的子进程运行相同的代码，它会成功返回该退出代码。

和崩溃代码

结果显示 0 退出代码和成功 error_code

单独运行 crash 可执行文件会返回 139 的退出代码

似乎 boost::process::system 正在泄漏 fds：

假设我有这个简单的代码每 3 秒刷新一次 iptables 配置（只是一个例子）：

如果我通过 list 观察打开文件描述符的计数/proc/PID/fd |wc -l，我可以看到计数每 3 秒增加 1。最终，当它到达 1024 时，程序将中止，因为该system调用将抛出异常并what()指出 打开的文件太多！

如何避免这种 fd 泄漏？我正在使用提升 1.69。

编辑：替换boost::process::system似乎boost::process::child没有帮助，child似乎也泄漏 fds，无论它是否分离。

编辑 2：Valgrind 日志--track-fds=yes： https ://termbin.com/d6ud

我有一些简单的应用程序：

当作为子进程运行的应用程序的标准输出中出现“2”时，我想在单独的应用程序中调用回调：

问题是我必须std::cin.get()在子进程中按下父进程中的任何按钮才能使 io_context 执行回调函数。你有什么建议让它按预期工作吗？

我有一定的问题，我不确定我做错了什么。

我想在我的应用程序中捕获 sleeper 的输出并将其逐行添加到某个容器中；

不幸的是，我的应用程序挂起context.run()，可能是因为睡眠应用程序永远不会终止。但它应该读取睡眠者的输出直到分隔符，所以我不知道这里有什么问题。我期待着一些解释。

在对主题进行更多研究后进行编辑：

根据： https: //support.microsoft.com/en-us/help/190351/how-to-spawn-console-processes-with-redirected-standard-handles

注意 使用诸如 printf() 和 fprintf() 之类的 C 运行时函数的子进程在重定向时可能表现不佳。C 运行时函数维护单独的 IO 缓冲区。重定向时，这些缓冲区可能不会在每次 IO 调用后立即刷新。因此，printf() 调用的重定向管道的输出或 getch() 调用的输入不会立即刷新，并且会出现延迟，有时甚至是无限延迟。如果子进程在每次调用 C 运行时 IO 函数后刷新 IO 缓冲区，则可以避免此问题。只有子进程可以刷新其 C 运行时 IO 缓冲区。进程可以通过调用 fflush() 函数刷新其 C 运行时 IO 缓冲区。

我仍在寻找该领域的解决方案。

我正在尝试在子进程中实现从/到同一管道的读取和写入。而不是管道，我正在使用并将子进程boost::process::pstream重定向到该流。stdinstdout

简单的例子。我从主进程向子进程发送一条消息，从子进程中读取它，然后将其发送回主进程。问题是我在主进程中从子进程接收到一个垃圾（空字符串）。我究竟做错了什么？

如果我对子进程的输入/输出使用单独的流，则下面的代码示例可以正常工作...

输出如下：

下面的示例代码在 Windows 上导致异常：

但这不是：

这是异常消息：

我在 Boost 文档中找到了一些关于 codecvt 的信息：

由于 windows 不使用 UTF-8，因此有时不可避免地使用 WinApi 的 wchar_t 版本。为了保持这个库的一致性，它还在 posix 上提供了 wchar_t 支持。

由于 posix api 纯粹是 char，因此每个基于 wchar_t 的类型都将转换为 char。

另一方面，Windows 更具选择性。默认是使用char，但是如果任何参数需要wchar_t，所有的东西都会被转换成wchar_t。这也包括 boost::filesystem::path。此外，如果系统不提供 char api（如 Windows CE 的情况），所有内容也将被转换。

但我认为我在这两种情况下都正确使用了子进程。你能告诉我我做错了什么吗？

我正在使用 boost::process::child 来生成新进程。我开始的过程的开始时间不是即时的，所以我必须等待一段时间才能完全初始化它。

在这个周期之后，我不再需要ipstream了。有什么方法可以将它与子进程分离？