[boost] Final opinion on Re: Boost.Fiber review January 6-15

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 
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/