Boost logo

Boost :

Subject: Re: [boost] [afio] AFIO review postponed till Monday
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-22 21:25:10

On 23 Jul 2015 at 5:37, Ben Pope wrote:

> To clarify; I think you're saying that your lightweight futures are
> close enough to free that you would prefer to implement your library
> with them as opposed to callback hell; and so, presenting the nicer
> future API poses no significant further performance penalty whilst
> presenting a nicer syntactic model.

That's a much better way of saying it yes.

The counter argument is that async_result allows third party supplied
synchronisation and is therefore much more flexible. I personally
think that means that our standard synchronisation primitives need to
up their game instead, and I've hopefully played my part in that.

> Personally I'm really interested in your lightweight futures for the
> same reason. Callback hell sucks; without profile information to the
> contrary, I'd rather just write code the nice way.

Of course you eliminate callback hell with standard futures and
coroutines already. I simply replace standard futures with faster
ones that do more stuff.

I have yet to benchmark Gor's coroutines when combined with
lightweight future promise. It's part of why I estimate four months
to rewrite the AFIO engine, as I would assume I'll need to pester him
with code examples of pathological performance corner cases :)

I also would like optional Boost.Fiber support in lightweight future
promise, that gains us coroutines on all platforms. But that's
probably later again right now as the lack of ability to relocate
fibers across threads is going to require some further reflection and
pondering from me.

Let me put this another way: I'm aiming to drop the dependency on
ASIO in the medium term because the coroutine reactor in the C++
language takes over, and therefore the ASIO reactor is no longer


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at