2014/1/7 Niall Douglas
Oh great! If you had a Design Rationale page which specifically says such a feature is out of scope for Boost.Fiber because it's a more complex additional layer which happens to be provided in another library X (preferably with link to it), then I would be very pleased.
I'll add an rational section to the documentation - the library is pre-alpha (e.g. I'm experimenting with some ideas - but if you are interested I can discuss it with you in a private email). Well ... I agree that thread cancellation support is probably a step
too far, but I think there is also a reasonable happy medium between C++11 and Boost.Thread.
I don't say that I'm against this - I've added fiber itnerruption (I would follow the suggestion from Herb Sutter that a thread/fiber should be cooperativ-cancelable == interruptable). I try to keep the interface small as possible - of course we can discuss which funtions should the interface contain.
Put it another way: what out of Boost.Thread's additions would look extremely likely to appear to C++17? The future::get_exception_ptr() is a very good example, it saves a lot of overhead when you're transferring exception state from one future to another.
This is one items which could be discussed. for instance I've concerns to add future::get_exception_ptr() because I believe it is not really required, it is only for convenience. The exception thrown by the fiber-function (function which is executed by the fiber) is re-thrown by future<>::get(). If you don't want the exception re-thrown you could simply add a try-catch-statement at the top-most level in your fiber-function and assign the catched example to an exception_ptr passed to the fiber-function. void my_fiber_fn( boost::exception_ptr & ep) { try { ... } catch ( my_exception const& ex) { ep = boost::current_exception(); } } boost::exception_ptr ep; boost::fibers::fiber( boost::bind( my_fiber_fn, boost::ref( ep) ) ).join(); if ( ep) { boost::rethrow_exception( ep); } I do think you need reference docs for the ASIO support classes. I'll do it
I don't understand what they do, and I think I ought to.
It is pretty simple - the fiber-scheduler contains a reference to asio's io_service and uses it a event-queue/event-dispatcher, e.g. it pushes fibers ready to run (e.g. fiber newly created, yielded fibers or signaled fibers suspended by a wait-operation on sync. primitives).
Sure. But it's a "why should I use this library?" sort of thing? If I see real world benchmarks for a library, it tells me the author has probably done some performance tuning. That's a big tick for me in considering to use a library.
well I did not performance tuning - my main focus was to get the library work correctly (optimizations will we done later).
It also suggests to me if refactoring my code is worth it. If Boost.Fiber provides only a 10x linear scaling improvement, that's very different from a log(N) scaling improvement. A graph making it very obvious what the win is on both CPU time and memory footprint makes decision making regarding Fiber support much easier.
I don't know the factor of fibers scaling - I would consider boost.fiber a way to simplify the code, e.g. it prevents scattering the code by callbacks (for instance in the context of boost.asio). my starting point was to solve problmes like the C10K-problem (Dan Kegel explains it in a more detail on its webpage - I'm referring to it in boost.fiber's documentation - http://olk.github.io/libs/fiber/doc/html/fiber/asio.html).
Put it another way: if I am asking my management for time to prototype adopting Fibers in the company's core software, a scaling graph makes me getting that time a cinch. Without that graph, I have to either make my own graph in my spare time, or hope that management understands the difference between fibers and threads (unlikely).
well that are the problems we are all faced to :) I've not done performance tests, sorry
Of course I could provide a benchmark for a simple task running a certain amount of fibers - but what would be a good example for such a task?
You don't need much: a throughput test of null operations (i.e. a pure test of context switching) for total threads 1...100,000 on some reasonably specified 64 bit CPU e.g. an Intel Core 2 Quad or better. I generally would display in CPU cycles to eliminate clock speed differences.
CPU cycles for context switching is provided for boost.context and boost.coroutine - but adapting the code for boost.fiber isn't an issue - I could addd it. Extra bonus points for the same thing on some ARMv7 CPU.
counting CPU cycles isn't that easy for ARM (at least as I was looking at it).
Eh, well then I guess you need a link to the correct page in boost.context where it lists the architectures it works on. Certainly a big question for anyone considering Fiber is surely "will it work on my CPU"?
the docu of boost.context is mising this info - I'll add it (could you add an bug-report for boost.context please).
Sure, but I definitely won't be using Fibers that way. And I saw Antony had the same observation too. I think you need some more docs on this: just tell us what is possible, what works and how it works and we'll figure out the rest. I definitely need the ability to signal a fibre future belonging to thread A from some arbitrary thread B. I'll also need to boost::asio::io_service::post() to an ASIO io_service running fibers in thread A from some arbitrary thread B.
yes, as I explained it is supported.Maybe because I've writen the code don't know why the documentation is not enought for you. what works is that you create fibers::packaged_task<> and execute it in a fiber on thread A and wait on fibers::future<> returned by packaged_task<>::get_future() in thread B.
The docs need to explicitly say so then, and indeed thread safety for *every* API in the library.
OK
Complexity guarantees and exception safety statements for each API would also be nice. I know they're a real pain to do, but it hugely helps getting the library into a C++ standard later.
OK
between two threads (this code shows how work-stealing/work-sharing can be implemented in a thread-pool).
If you have a section in a design rationale page saying this, I would be happy.
OK I think, as a minimum, all the examples need to appear verbatim in
the docs
the complete code? I would prefer only code snippets - the complete code be read in the example directory. otherwise the documentation would be bloated (at least I would skip pages of code).