Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Bjorn Reese (breese_at_[hidden])
Date: 2016-11-13 07:23:47

On 11/07/2016 01:46 AM, Klemens Morgenstern wrote:

> I didn't understand it that way, especially since he Bjorn mentioned
> boost::thread. I'm a bit tired of this discussion, and Boris explained
> very well, why the initializers-approach was chosen. As far as I
> understand it he considers everything but args as attributes and wants
> them all crammed into one type (or something like that) which would be a
> horrific mess. I should know, I tried to build somethinke like that
> (based on boost.process), just two ours ago - it doesn't work for a
> proper process library, there are just too many properties to a process.

"Horrific mess" is in the eye of the beholder.

With the current API it is unclear which parameters are mutually
exclusive (e.g. can I pass both a yield context and an error_code?)
or what happens if I specify the same attribute multiple times like
this:

   bp::child c(command,
               bp::std_out > p,
               bp::std_out > "output.txt");

and of course the argument overwrite issue mentioned by Lee, all of
which demonstrates that the current API is error-prone.

The discussion about attributes is a bit fuzzy because the library does
not define what they are. After a closer look it appears that there are
several categories of attributes crammed into the initializer list.

One such category is the status-reporting (e.g. error_code and yield
context.) Here is another idea for an API: have separate functions for
synchronous and asynchronous invocation.

Let the synchronous invocation accept one command parameter, one
optional attributes parameter, zero or more arguments, and one optional 
error_code. The latter determine whether the call throws or not. I am
deliberately omitting the attributes parameter below because it is
irrelevant to the sync/async split.

   bp::system(command, arguments...); // throws
   bp::system(command, arguments..., error_code&) nothrow;

Let the asynchronous invocation accept one io_service parameter, one
command parameter, one optional attributes parameter, zero or more
arguments, and one handler/extension parameter (i.e. no error_code
parameter.)

   bp::async_system(io, command, arguments..., [](error_code){});
   bp::async_system(io, command, arguments..., yield);

This solves the error_code versus yield context issue, and it further
more enables more capable extensions (see my next mail) such as for
Boost.Fiber.