Home | Libraries | People | FAQ | More |
In this section we will go step by step through the different features of boost.process. For a full description see the reference and the concepts sections.
We want to start a process, so let's start with a simple process. We will invoke the gcc compiler to compile a simple program.
With the standard library this looks like this.
int result = std::system("g++ main.cpp");
Which we can write exactly like this in boost.process.
namespace bp = boost::process; //we will assume this for all further examples
int result = bp::system
("g++ main.cpp");
If a single string (or the explicit form bp::cmd
),
it will be interpreted as a command line. That will cause the execution function
to search the PATH
variable
to find the executable. The alternative is the exe-args
style,
where the first string will be interpreted as a filename (including the path),
and the rest as arguments passed to said function.
Note | |
---|---|
For more details on the |
So as a first step, we'll use the exe-args
style.
int result = bp::system
("/usr/bin/g++", "main.cpp");
With that sytax we still have "g++" hard-coded, so let's assume
we get the string from an external source as boost::filesystem::path
,
we can do this too.
boost::filesystem::path p = "/usr/bin/g++"; //or get it from somewhere else.
int result = bp::system
(p, "main.cpp");
Now we might want to find the g++
executable in the PATH
-variable,
as the cmd
syntax would do.
Boost.process
provides a function to this end:
bp::search_path
.
boost::filesystem::path p =bp::search_path
("g++"); //or get it from somewhere else. int result =bp::system
(p, "main.cpp");
Note | |
---|---|
|
Given that in our example used the system
function, our program will wait until the child process is completed. This
maybe unwanted, especially since compiling can take a while.
In order to avoid that, boost.process provides several ways to launch a process.
Besides the already mentioned system
function and it's asynchronous version async_system
,
we can also use the spawn
function or the child
class.
The spawn
function
launches a process and immediately detaches it, so no handle will be returned
and the process will be ignored. This is not what we need for compiling,
but maybe we want to entertain the user, while compiling:
bp::spawn
(bp::search_path
("chrome"), "www.boost.org");
Now for the more sensible approach for compiling: a non-blocking execution.
To implement that, we directly call the constructor of child
.
bp::child
c(bp::search_path
("g++"), "main.cpp"); while (c.running
()) do_some_stuff(); c.wait
(); //wait for the process to exit int result = c.exit_code
();
So we launch the process, by calling the child constructor. Then we check
and do other things while the process is running and afterwards get the exit
code. The call to wait
is necessary, to obtain it and tell the operating system, that no one is
waiting for the process anymore.
Note | |
---|---|
You can also wait for a time span or a until a time point with |
Warning | |
---|---|
If you don't call wait on a child object, it will be terminated on destruction.
This can be avoided by calling |
Until now, we have assumed that everything works out, but it is not impossible, that "g++" is not present. That will cause the launch of the process to fail. The default behaviour of all functions is to throw an std::system_error on failure. As with many other functions in this library, passing an std::error_code will change the behaviour, so that instead of throwing an exception, the error will be a assigned to the error code.
std::error_code ec;
bp::system
c("g++ main.cpp", ec);
In the examples given above, we have only started a program, but did not consider the output. The default depends on the system, but usually this will just write it to the same output as the launching process. If this shall be guaranteed, the streams can be explicitly forwarded like this.
bp::system
("g++ main.cpp",bp::std_out
> stdout,bp::std_err
> stderr,bp::std_in
< stdin);
Now for the first example, we might want to just ignore the output, which can be done by redirecting it to the null-device. This can be achieved this way:
bp::system
("g++ main.cpp",bp::std_out
>bp::null
);
Alternatively we can also easily redirect the output to a file:
bp::system
("g++ main.cpp",bp::std_out
> "gcc_out.log");
Now, let's take a more visual example for reading data. nm
is a tool on posix, which reads the outline, i.e. a list of all entry points,
of a binary. Every entry point will be put into a single line, and we will
use a pipe to read it. At the end an empty line is appended, which we use
as the indication to stop reading. Boost.process provides the pipestream
(ipstream
, opstream
, pstream
)
to wrap around the pipe
and provide an implementation of the std::istream,
std::ostream
and std::iostream
interface.
std::vector<std::string> read_outline(std::string & file) {bp::ipstream
is; //reading pipe-streambp::child
c(bp::search_patk("nm"), file,bp::std_out
> is); std::vector<std::string> data; std::string line; while (c.running
() && std::getline(is, line) && !line.empty()) data.push_back(line); c.wait
(); return data; }
What this does is redirect the stdout
of the process into a pipe and we read this synchronously.
Warning | |
---|---|
The pipe will cause a deadlock if you try to read after nm exited |
Note | |
---|---|
You can do the same thing with |
Now we get the name from nm
and we might want to demangle it, so we use input and output. nm
has a demangle option, but for the sake
of the example, we'll use c++filt
for this.
bp::opstream
in;bp::ipstream
out;bp::child
c("c++filt", std_out > out, std_in < in); in << "_ZN5boost7process8tutorialE" << endl; std::string value; out >> value; c.terminate
();
Now you might want to forward output from one process to another processes input.
std::vector<std::string> read_demangled_outline(const std::string & file) {bp::pipe
p;bp::ipstream
is; std::vector<std::string> outline; //we just use the same pipe, so thebp::child
nm(bp::search_path
("nm"), file,bp::std_out
> p);bp::child
filt(bp::search_path
("c++filt"),bp::std_in
< p,bp::std_out
> is); std::string line; while (filt.running() && std::getline(is, line)) //when nm finished the pipe closes and c++filt exits outline.push_back(line); nm.wait
(); filt.wait(); }
This forwards the data from nm
to c++filt
without your process needing to do
anything.
Boost.process allows the usage of boost.asio to implement asynchronous I/O.
If you are familiar with boost.asio
(which we highly recommend), you can use async_pipe
which is implemented as an I/O-Object and can be used like pipe
as shown above.
Now we get back to our compiling example. nm
we might analyze it line by line, but the compiler output will just be put
into one large buffer.
With boost.asio this is what it looks like.
boost::asio::io_service ios; std::vector<char> buf;bp::async_pipe
ap(ios);bp::child
c(bp::search_path
("g++"), "main.cpp",bp::std_out
> ap); boost::asio::async_read(ap, boost::asio::buffer(buf), [](const boost::system::error_code &ec, std::size_t size){}); ios.run(); c.wait(); int result = c.exit_code();
To make it easier, boost.process provides simpler interface for that, so that the buffer can be passed directly, provided we also pass a reference to an boost::asio::io_service.
boost::asio::io_service ios; std::vector<char> buf;bp::child
c(bp::search_path
("g++"), "main.cpp",bp::std_out
> boost::asio::buffer(buf), ios); ios.run(); c.wait(); int result = c.exit_code();
Note | |
---|---|
Passing an instance of boost::asio::io_service
to the launching function automatically cause it to wait asynchronously
for the exit, so no call of |
To make it even easier, you can use std::future
for asynchronous operations (you will still need to pass a reference to a
boost::asio::io_service)
to the launching function, unless you use bp::system
or bp::async_system
.
Now we will revisit our first example and read the compiler output asynchronously:
boost::asio::boost::asio::io_service ios; std::future<std::string> data; child c("g++", "main.cpp", //set the inputbp::std_in
.close(),bp::std_out
>bp::null
, //so it can be written without anythingbp::std_err
> data, ios); ios.run(); //this will actually block until the compiler is finished auto err = data.get();
When launching several processes, processes can be grouped together. This
will also apply for a child process, that launches other processes, if they
do not modify the group membership. E.g. if you call make
which launches other processes and call terminate on it, it will not terminate
all the child processes of the child unless you use a group.
The two main reasons to use groups are:
If we have program like make
,
which does launch it's own child processes, a call of terminate
might not suffice. I.e. if we have a makefile launching gcc
and use the following code, the gcc
process will still run afterwards:
bp::child
c("make"); if (!c.wait_for
(std::chrono::seconds(10)) //give it 10 seconds c.terminate
(); //then terminate
So in order to also terminate gcc
we can use a group.
bp::group
g;bp::child
c("make", g); if (!g.wait_for
(std::chrono::seconds(10)) g.terminate
(); c.wait
(); //to avoid a zombie process & get the exit code
Now given the example, we still call wait
to avoid a zombie process. An easier solution for that might be to use spawn
.
To put two processes into one group, the following code suffices. Spawn already launches a detached process (i.e. without a child-handle), but they can be grouped, to that in the case of a problem, RAII is still a given.
void f() {bp::group
g;bp::spawn
("foo", g);bp::spawn
("bar", g); do_something(); g.wait
(); };
In the example, it will wait for both processes at the end of the function unless an exception occures. I.e. if an exception is thrown, the group will be terminated.
Please see the reference
for more information.
This library provides access to the environment of the current process and allows setting it for the child process.
//get a handle to the current environment auto env =boost::this_process::environment
(); //add a variable to the current environment env["VALUE_1"] = "foo"; //copy it into a environment seperate to the one of this processbp::environment
env_ = env; //append two values to a variable in the new env env_["VALUE_2"] += {"bar1", "bar2"}; //launch a process with `env_`bp::system
("stuff", env_);
A more convenient way to modify the environment for the child is the env
property, which the example as
following:
bp::system
("stuff",bp::env
["VALUE_1"]="foo",bp::env
["VALUE_2"]+={"bar1", "bar2"});
Please see to the reference
for more information.