Subject: [boost] Final opinion on Re: Boost.Fiber review January 6-15
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-01-11 06:13:07
On 10 Jan 2014 at 18:46, Oliver Kowalke wrote:
> > It's this kind of stuff which documentation is for, and why at least
> > one person i.e. me needs hand holding through mentally groking how
> > the ASIO support in Fiber works. Sorry for being a bit stupid.
> the other case you are referring to is the async-feature of boost.asio.
> Chris has already implemented the async-feature for coroutines (from
> boost.coroutine). so the best source of the internal working is the docu
> of boost.asio. I've added support of asio's async-feature for fibers,
> e.g. if provided some classes required to use fibers in the context of
> asio and its async-operations (for instance async_read() see examples).
> usaly this code should belong to boost.asio instead boost.fiber -
> anyway, because boost.fiber is new I've added it in my lib.
Aha! You're reusing ASIO's coroutines support as-is. For some reason
my old brain didn't grok this, now it does. Thank you Oliver, and for
putting up with my stupid questions.
Ok I think I am now ready to give my final peer review:
Acceptance: I recommend yes, provided considerable improvements are
done on the following areas:
* It needs to be explicitly documented per API which of the support
classes are thread safe (I discovered above that's almost all of
* More identical replication of Boost.Thread's specific APIs. Others
have gone into more detail on this than I, but I would add that if an
extension API is trivial to add, I'd say it's very likely to appear
in C++17 anyway.
* Basically condense this thread of discussion into docs on the ASIO
support. Say explicitly you're reusing ASIO's coroutines support
as-is, and link to ASIO's coroutines docs pages.
* Need to see performance scaling results as N fibers of execution
rise. Need to see CPU cycles and memory consumption in those results.
* Need a link to Coroutine's list of supported architectures.
* C++11 support needs improving. Others have mentioned more on this
* Include the code examples into the docs so Googlebot can find them.
Like ASIO does at
* You definitely absolutely need a Design Rationale page explaining
why what's in Fiber is there, and why what isn't is not. Do link to
external libraries extending Fiber with "missing" features if
Nice to have:
* Intel TSX support to avoid locks.
* Complexity guarantees and exception safety statements per API.
Oliver: you did a great job on Fiber and Coroutine. Please accept my
personal thank you for all your hard work and making it available to
the Boost community.
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk