Boost logo

Boost :

Subject: Re: [boost] Boost.Process article: Tutorial and request for comments
From: Boris Schaeling (boris_at_[hidden])
Date: 2009-04-25 08:52:24

On Tue, 21 Apr 2009 20:15:11 +0200, Phil Endecott
<spam_from_boost_dev_at_[hidden]> wrote:

> [...]First a general comment about how I would prefer that portable
> system API wrappers are implemented. No doubt other would have
> different views. Ideally, I'd like to see separate thin wrappers for
> Windows and POSIX that just "C++-ify" those APIs. Then on top of that
> implement a portability layer. My reason is this: I rarely if ever care
> about Windows and I already know how the POSIX APIs work (i.e. what the
> functions are called and what the semantics are). So please don't hide
> the bottom level thin wrappers that you must have as an implementation
> detail.

I see. It reminds me a bit of the free-standing functions in
Boost.Filesystem which I think simply call POSIX and Windows API
functions? I'm not sure though if I can work on such a layer - I hardly
have time to work on the upper layer. :-/

> Re the environment: I'm not enthusiastic that you have copied the
> environment into your own data structure. Why can't your environment
> type just wrap getenv() and setenv()? i.e.

Before I answer your questions I should note that I did not design
Boost.Process. I went through the entire code last year to make sure that
what we have works (fixing countless bugs and testing the library with
numerous compilers and platforms). I try to answer your questions as far
as I understand the rationale of the design.

> class environment {
> struct env_var_proxy {
> const char* varname;
> env_var_proxy(const char* varname_): varname(varname_) {}
> operator const char*() const { return getenv(varname); }
> void operator=(const char* newval) { setenv(varname,newval,1); }
> }

The type environment is also used to setup a new environment for a child
process, eg.:

context ctx;
ctx.environment.insert(environment::value_type("PATH", "/newpath"));
launch(..., ctx);

> [...]This example code:
> std::string exec = find_executable_in_path("notepad.exe");
> std::vector<std::string> args = boost::assign::list_of("notepad.exe");
> context ctx;
> ctx.environment = self::get_environment();
> launch(exec, args, ctx);
> Is actually more verbose than directly calling the POSIX functions:
> int child_pid = fork();
> if (child_pid == -1) throw "fork failed";
> if (child_pid == 0) {
> execlp("notepad.exe","notepad.exe",NULL);
> _exit(1);
> }
> Why don't you boil it down to:
> launch_process("notepad.exe");

Currently the environment variables of the current process are not
automatically inherited by a child process. I agree that it should be
easier to launch a new process. But then environment variables should
probably be inherited by default?

> You write:
>> it is very important to refer to the executable with an absolute path -
>> on all platforms including POSIX systems
> Why do you say that?

It's a requirement of Boost.Process. It doesn't need to be an absolute
path but can also be a relative path of course. What's not guaranteed
though is that an executable is automatically found when only a filename
is given. There is a function which searches for an executable and returns
an absolute path. Would you like to see Boost.Process search for an
executable automatically?

> It's not clear to me if your terminate() calls wait() or not. Beware of
> processes that ignore SIGCHLD.

Currently terminate() only calls kill().

>> 3) Currently Boost.Process is really only useful for creating child
>> processes. It's not possible for example to detect and iterate over
>> other
>> processes on a system. I guess Boost.Process should be enhanced here.
>> Then
>> one day the well-known utility 'ps' on POSIX systems could be
>> implemented
>> in Boost C++. Any comments?
> What is the use case for this?

I asked myself the other way round: Why should a library for process
management only support child processes? But I'd agree that accessing
other processes has a lower priority.

> [...]
>> 8) There is a method wait() which makes it possible to wait for another
>> process to exit. Currently wait() is provided by the class child though.
>> Shouldn't it really be defined by the class process (so you can wait not
>> only for child processes to exit)?
> Are you certain that wait() can be used to monitor non-child processes?
> I don't believe that it can.

Hm, on POSIX systems it doesn't work but on Windows it works. Another
problem to think about.


Boost list run by bdawes at, gregod at, cpdaniel at, john at