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 them). * 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 than I. * Include the code examples into the docs so Googlebot can find them. Like ASIO does at http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/examples.html * 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 appropriate. Nice to have: * Intel TSX support to avoid locks. * Complexity guarantees and exception safety statements per API. Lastly: 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. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/