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

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-07 17:07:12

2014/1/7 Niall Douglas <s_sourceforge_at_[hidden]>

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