Re: [boost] Push/pull parsers & coroutines (Was: Boost.HTTPKit, a new library from the makers of Beast!)

Subject: Re: [boost] Push/pull parsers & coroutines (Was: Boost.HTTPKit, a new library from the makers of Beast!)
From: Seth (bugs_at_[hidden])
Date: 2017-10-14 15:03:19

On 13-10-17 20:59, Phil Endecott via Boost wrote:
> Specifically, I've been wondering 
> whether the imminent arrival of low-overhead coroutines ought to 
> change best practice for this sort of interface.

That's nice, but it can't inform the design of a library that exists
now. Of course, the interface would be best served if it didn't exclude
better¹ options in the future.

¹ coroutines are not zero cost

On 13-10-17 20:59, Phil Endecott via Boost wrote:
> Now, with stackless coroutines due "real soon now", we can avoid 
> needing explicit state on either side.

Coros have explicit state but with syntactic sugar. The syntactic sugar
in this case has runtime overhead.

> Questions: how efficient is this in practice?  

In practice it should be profiled, but it _will_ have overhead.

> Is this really simpler to write than a non-coroutine version?
>
In all but the most trivial cases I think it's simpler. To write.

> Will all of our code use this style in the (near?) future?
>
Will all of our code use this style: Most definitely not (because then
we'd not be using C++, the language that exists to eliminate overhead)

> How should we be writing code now so that it is 
> compatible with this style in the future?
This is the most relevant question. I applaud it being asked. I don't
have the answer yet.
Slightly related, in my book, may be the way in which Boost Asio caters
for different async patterns (yield_context, use_future or direct
handlers). Asio coded the logic into the async_result customization
point.
(http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/async_result.html)

I suppose we could learn by assimilating a device like that.

Seth