Re: [boost] Formal Review of Proposed Boost.Process library

Subject: Re: [boost] Formal Review of Proposed Boost.Process library
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-02-19 17:49:34

> The  Boost.Process must be implemented as a DSEL (probably through the 
> Boost.Proto expression templates framework) with a nice (commonly known) 
> syntax like:
> 
> using boost::process;
> using  process::arg;
> namespace fs = boost::filesystem;
> 
> process ls("ls"),  grep("grep");
> fs::path libs = "/usr/lib";
> 
> auto pipe = ls  [--arg("reverse") % -arg('l') % libs]  |  grep  ["^d"];
> 
> run(pipe);
> //   or:
> // pipe();
> //   or:
> //  ls();

I would strongly disagree with that. C++ is too "cryptic"
enough so having simple, clear and readable interfaces
for average programmer is very critical.

If it had such interface it would get my vote off.

> 
> This approach provide a declarative, not an imperative programming  style. (A 
> lot of work done by expression templates' inner  mechanics.)
> 
> The library must support:
> 
> * i/o redirection
> *  process piping; [implicit pipes]
> * named/unnamed pipe objects; [explicit  pipes]
> * runned processes surfing  (boost::process::processes_iterator):
>   -  CreateToolhelp32Snapshot()/Process32First()/Process32Next() API 
> functions in  Windows
>   - /proc filesystem parsing in linux/some unix
> * loaded  shared libraries surfing (boost::process::modules_iterator):
>   -  CreateToolhelp32Snapshot()/Module32First()/Module32Next() API functions 
> in  Windows
>   - /proc filesystem parsing in linux/some unix
> * child  processes surfing (boost::process::children_iterator)
>   - parsing  processes_iterator's range results
>   - /proc filesystem parsing in  linux/(perhaps) some unix
>   - empty iterator range by default
> *  runned thread per process surfing (boost::process::threads_iterator)
>   -  filtered results of 
> CreateToolhelp32Snapshot()/Thread32First()/Thread32Next() API functions in 
> Windows
>   - /proc filesystem parsing in linux (see /proc/[pid]/task  filesystem 
> branch since linux 2.6.0-test6)
>   - empty iterator range  by default
> * runned thread surfing (boost::threads_iterator)
>   -  CreateToolhelp32Snapshot()/Thread32First()/Thread32Next() API functions 
> in  Windows
>   - FOR-EACH process IN system:
>        back_inserter(boost::process::threads_iterator(process),
>                       boost::process::threads_iterator(),
>                      threads);
> * (any) process stats
> * process  creation
> * daemonization
>   - through Service API on Windows
> *  process security and privacy aspects (probably this is subject for an 
> another separate library, part of which must be integrated with the 
> Boost.Process)
> 

There are many nice features features that may be useful but:

1. Most of them are not "must-to-have" for process library, there
   may be other libraries that do it but not boost.process.
2. Many things like service handling are just not possible or
   feasible to implement in cross platform way. Windows services
   and Posix deamons are too different.
3. Same for security model on Windows and POSIX OS so making
   "same" interface would give nothing.

   For example try to loose process rights under Windows like it
   is done under Unix platform.

Artyom