Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-20 20:48:51

Oliver,

> > I asked that because Oliver seems to me to be focusing many of his
> > replies in this thread and elsewhere to "it makes Asio syntax
> > cleaner", which I don't feel is a sufficient justification for this
> > library to exist by itself, because Coroutine already does that.
> 
> correct - but think on the one-thread-per-clientpattern (which most
> developers are familiar with) which is easy to write and understand than
> using callbacks - both using asnyc I/O.
> one-thread-per-client -> one-fiber-per-client with coroutines you can't
> use the one-fiber-per-client because you are missing the synchronization
> classes.

After some more thinking I believe to start understanding the angle you're
coming from. The proposed library has been designed for the sole purpose of
complementing Boost.Asio (or similar asynchronous libraries), allowing it to
be used in a more straightforward way. I apologize for being slow or dense.

Using the name Boost.Fiber implies a much broader use case (and that's what
got me confused). I think it would be sensible to choose another name for
this library. 

BTW, if the author would have referred to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf, all these
misunderstandings could have been avoided...

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> 
> 
> > If you are running on a single thread, you do not require any locks at
> > all on the queue, and barely any kind of synchronisation to have
> > consumers go to sleep when idle and be woken up when new work arrives.
> >
> 
> hmm - the library doesn't uses locks in the sense of thread-locks
> 
> fibers are a thin wrapper around coroutines and you are able to do
> something like:
> 
> void fn1() {};
> fiber f1(fn1);
> 
> void fn2() { f1.join(); }
> fiber f2( fn2);
> 
> e.g. a fiber can join another fiber as you know it from threads
> (coroutines do not provide this feature or you would have to implement it
> as boost.fiber already tries to provide).
> 
> 
> >
> > Although granted this library would theoretically make life easier
> > than the alternatives if the consumers also needed to sleep on things
> > other than the queue itself -- though again, if you're running in one
> > thread you don't need locks, so there's not much you need to sleep on.
> >
> 
> fiber does not sleep - they are suspended (its stack and registers are
> preserved) and if the condition for which the fiber was suspended becomes
> true it will be resumed, e.g. the registers are restored in the cpu and
> the stackpoint is restored too. so it is not real locking as threads but
> the fiber library provides classes as std::thread API (but the internal
> implementation and the used mechanisms are different).
> 
> 
> > It's only really when you go to M:N that something like this becomes
> > especially valuable.
> >
> 
> not realy even if you do cooperative scheduling == userland-threads (which
> can run concurrently in one thread) you need classes for coordinating the
> fibers _______________________________________________
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost