[Process] Proposed solution for posix pipes staying open

Hello, I'm new to Boost and looking for some help on the right process to propose patches. I'm running in an embedded Linux environment (OpenBMC) using Boost 1.69.0 and just switched a couple of std::system() calls to boost::process::system() calls. After making this change, I noticed that each time my process executed the bp::system() call, I would get an extra pipe fd in my /proc/<pid>/fd list. I did some debugging and have found a possible solution for this issue in the Boost.Process posix headers that I would like to propose. What is the right forum or process to post my patch (post it here, github pull request, etc.)? Thanks! -Jason

A pull request at GitHub.com/klemens-morgenstern/boost-process would be the preferred one for me. This probably the pipe for error handling, which you can disable with ignore_error - though that should be closed after launching the process.

On 3/21/2019 6:01 PM, Klemens via Boost wrote:
A pull request at GitHub.com/klemens-morgenstern/boost-process would be the preferred one for me.
Done. Created pull request #193: https://github.com/klemens-morgenstern/boost-process/pull/193
This probably the pipe for error handling, which you can disable with ignore_error - though that should be closed after launching the process.
Yes, it is the pipe for error handling. I found the ignore_error setting, which also worked, but needed to be applied to all calls, which was not ideal. I see that PR #77 was just merged which added a ::close() call to fix the same issue that I'm looking at. However, there are still some paths that return from _read_error() without closing the pipe, so I'm proposing to move the ::close() call outside of _read_error(), so it doesn't have to be handled in all return cases. Thanks! -Jason
participants (2)
-
Bills, Jason M
-
Klemens