2014/1/7 Niall Douglas
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).
Thing is ... the C10K problem *is* a performance problem. If you're going to suggest that Boost.Fiber helps to solve or does solve the C10K problem, I think you need to demonstrate at least a 100K socket processing capacity seeing as some useful work also needs to be done with the C10K problem. Otherwise best not mention the C10K problem, unless you're saying that you hope in the near future to be able to address that problem in which case the wording needs to be clarified.
my focus was to address the one-thread-per-client pattern used for C10K. the pattern makes code much more readable/reduces the complexity but doesn't scale. if you create too many threads on your system your overall performance will be shrink because at a certain number of threads, the overhead of the kernel scheduler starts to swamp the available cores.
I appreciate and understand this. However, I must then ask this: is your library ready to enter Boost if you have not done any performance testing or tuning?
is performance testing and tuning a precondition for a lib to be accepted? I did some tuning (for instance spinlock implementation) but it is not finished.
How about this? Can you do a side-by-side code example where on the left side is an old style ASIO callback based implementation, and on the right is an ASIO Fiber based implementation? Something like https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/async_file_io/hello_world.ht ml.
OK
It doesn't have to be anything more than a trivial Hello World style toy thing. I just need to map in my head what yield[ec] means, and how that interplays with boost::fibers::asio::spawn and io_service::post().
- io_service::post() pushes a callable to io_service's internal queue (executed by io_service::run() and related functions) - fibers::asio::spawn() creates a new fiber and adds it to the fiber-scheduler (specialized to use asio's io_service hence asios's asyn-result feature) - yield is an instance of boost::fibers::asio::yield_context which represents the fiber running this code; it is used by asio's async result feature - yield[ec] is put to an async-operation in order suspending the current fiber and pass an error (if happend during execution of async-op) back to the calling code, for instance EOF if socket was closed
Also one last point: your fiber condvar seems to suffer from no spurious wakeups like pthread condvars? You're certainly not protecting it from spurious wakeups in the example code. If spurious wakeups can't happen, you *definitely* need to mention that in the docs as that is a much tighter guarantee over standard condvars.
OK