Boost logo

Boost :

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

      


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk