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 necessary. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/