|
Boost : |
Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Bjorn Reese (breese_at_[hidden])
Date: 2016-11-20 06:48:20
On 11/13/2016 02:54 PM, Klemens Morgenstern wrote:
> Well this will use the second pipe, though I grant you, that's not the
> best solution here - an error would be better. I could add an assertion,
> so there are no duplicates of that. On the other hand it is similar to
> that:
>
> child_builder cb;
> cb.std_out(p);
> cb.std_out("output.txt");
This can be turned into a compiler error. See the sqlpp11 for
inspiration.
> That's not the same. std::error_code is used to avoid exceptions and is
> only used when the process is launched. On exit you don't get an
> error_code, but only the exit-code of the process; and another
The exit code is the "return value" (quoted because it is actually
"returned" as an input parameter to the handler) and thus irrelevant
to the discussion about error_code versus yield context.
> std::error_code in case something went wrong with waiting. So there's no
> std::error_code vs. yield_context, they do different things and it
> actually makes sense to use them together.
> Now in case you use your error_code with system, like that
>
> bp::system("foo", ec, yield);
>
> ec being set will indicate that the process was not launched
> successfully and hence the coroutine wasn't suspended.
That is not how (asio) asynchronous operations work. Errors must be
reported via the handler, which in this case is the yield context.
Another important requirement is that the handler is not called
directly from the initiating function. See:
http://www.boost.org/doc/html/boost_asio/reference/asynchronous_operations.html
The error_code is reported via the yield context as "yield[ec]".
For yield context it may not seem like much of a difference (besides
the fact that with your approach we do not yield in the error case,
and therefore may starve other competing yield context) but for other
async_result constructs the difference is significant.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk