Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-20 11:04:34
Am 20.11.2016 um 15:02 schrieb Bjorn Reese:
> On 11/20/2016 01:38 PM, Klemens Morgenstern wrote:
>> How? How can I turn a sequence of calls valid when the object stays the
>> same and each call is valid?
> Look at the sqlpp11 codebase.
Look, I can see (as in sqlpp11) that this won't work, and yield a
but not the one that was in the prior E-Mail:
Could you please explain how that works, since you claimed it does? We
were talking about a specifc example, so please explain it to me.
>> I'm sorry, but I think you still do not understand how that works.
> Oh I understand it perfectly fine. I am pointing out that your yield
> integration does not fulfill the requirements for asynchronous
> operations. Look at the Asio references implementation and tell me if
> you can find any async_ functions that take an error_code output
No, but who - except you - cares?
>> Two things can hapen:
>> 1. The process launches successfully
>> --> No error in ec, the coroutine is suspended the wait-handle might
>> fail, which is not captured (but could be with yield[ec_yield])
>> 2. The process does not launch
>> --> ec is set, the couroutine is NOT suspended and nor error can
>> occur since the code does not wait for the handle (obviously, since
>> there is none) so yield does nothing.
> Case 2 is where you deviate from the Asio model.
> Normally we post a function on the io_service that calls the handler
> with the error to fullfil the requirement that all errors are reported
> via the handler.
It is not a regular async-function and there is only one async-operation
- so why would I be forced to do that? It's a feature, that allows you
to use exactly one thing, the yield_context, with boost.asio. So it's
not a general anync-operation. If I implement the error reporting with
yield[ec] I'll break my interface style. And that would destroy part of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk