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

Subject: Re: [boost] [boost.process] 0.6 Alpha
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2016-06-06 05:13:42

On 4 June 2016 at 21:52, Klemens Morgenstern <klemens.morgenstern_at_[hidden]>
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
>
>

So far I had time only to go quickly through the documentation and a bit in
the code so here are quick remarks:

1. It is not clear at all what happen when child object is destroyed.
2. The way child process termination is implemented for each platform
should be documented.
3. On most platforms there is a way to send a "quit" command to the process
and a way to kill it by force ("kill -9").
   Clarifying what is happening in the default cases and having a way to
terminate one way or the other (or a combination of
   both, that is requesting termination but force-kill after a time if it
didn't die)
   On windows there is an issue with this because the "termination request"
message can only be received if
   you didn't build a console application but a windows application (with a
WinMain) but that only means
   that the message could be ignored by the process if it's console
application (there are ways to have both WinMain and
   a console window, it's just a bit more clumsy to setup).

   In our (Softbank Robotics EU) use of child process tracking we need both
termination request and forced.

   One could argue that the termination request do not need to be
implemented by this library but it would be very useful
   to have a cross platform function doing this for simple cases.

Joël Lamotte