Re: [boost] [boost.process] 0.6 Alpha

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2016-06-16 10:26:00

On 04/06/2016 21:52, Klemens Morgenstern wrote:
> Hi all,
>
> the boost.process 0.6 library is now in alpha, that is: it has some
> (compiling) examples, a documentation and tests that pass on windows
> as well as on linux.
>
> It basically allows you to manage a process like this:
>
> pstream pipe;
>
> child c("some_prog", "--some-arg", env["PATH"]+="C:/stuff", std_in <
> "data.csv", std_out > pipe, std_err > null, start_dir="./bin");
>
> std::string data;
> pipe >> data;
>
> c.wait();
> cout << c.exit_code() << endl;
>
> You can find the documentation here:
> http://klemens-morgenstern.github.io/process/
> Get the source code from here:
> https://github.com/klemens-morgenstern/boost-process
>
> If you want to use it on windows, you currently would need to clone my
> boost.winapi fork also: https://github.com/klemens-morgenstern/winapi
>
> As for the scope of the library, it is meant to implement a small,
> portable layer to allow platform-independent process management.
> Thereby it's functionality is (unless I missed something) basically
> what is possible on posix as well as on windows. There are some
> platform extension, but I would not recommend to use them. It is also
> possible (though not yet documented) to write extensions, and if they
> work on both platforms I will gladly add them.
>
> It is however not the goal of the library, to be the be-all and
> end-all of process management; in past disscussions, different ideas
> where brought up, like implementing a DSEL for that or only allowing
> asynchronous communication. This library will never be that, since it
> would be much more fitting to build this on-top of it. E.g. a DSEL
> could be written (e.g. boost.shell) using boost.process underneath, so
> the library could concentrate only on the DSEL.
>
> It doesn't depend on boost.iostreams anymore, though it still uses
> boost.asio, boost.fusion and boost.filesystem.
>
> As for the open issues: some error handling is still lacking (but
> that'd be something like being unable to duplicate a handle), which
> would be required for proper extension, which is also why it's not
> documented.
> Also there's still an open discussion about the naming of the class
> and functions (child, system, spawn), so that may change also. But I
> consider this simple enough for a easy refactoring. If anyone has
> naming ideas, please tell me. One Idea was 'subprocess' but
> 'process::subprocess' just looks too strange to me.
>
> I hope you try it out, and give me some feedbacks. Or write angry
> error reports, both helps.
>
> Thanks!
>
> Klemens
>
Hi Klemens,

We have been using the Boost.Process state from Boris Schäling for more
than 3 year in productive use on linux embedded devices, and one thing
that we had to change is to use vfork instead of the fork function.

The problem with the fork + execve is that it produce a RAM copy of the
process page, while vfork+execve just don't. And when the parent process
launching child is pretty big, imagine a jvm using some jni library
using Boost.Process... it duplicates the whole Jvm im RAM to then
deallocate all at the moment of execve. vfork doesn't have this issue on
linux.

Without the use of vfork, you end up in situations where you get the
following error:  `boost::process::detail::posix_start: fork(2) failed:
Cannot allocate memory`

I think changing from fork to vfork is not much and brings alot of
advantages, but one must be aware that at_fork handler won't be called.
But this is not important as fork is used to do execve afterwards in
Boost.Process.

Cheers,
--
Damien Buhl
alias daminetreg