Subject: Re: [boost] [Fibers] Performance
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2014-01-16 11:28:13
On Thu, Jan 16, 2014 at 4:19 PM, Bjorn Reese <breese_at_[hidden]>wrote:
> On 01/16/2014 01:51 PM, Giovanni Piero Deretta wrote:
> I think that Harmut point is that you can very well use threads for the
>> same thing. In this particular case you would just perform a syncronous
>> read. Yes, to mantain the same level of concurrency you need to spawn ten
> Let me add two use cases that cannot be handled reasonably that way.
> First, many third-party libraries have callbacks as their primary
> interaction mechanism, and unlike Asio, they do not provide a
> synchronous alternative for the interaction.
You do not need to sell me the advantage of using continuations for
managing callback hell :) ...
> In this case fibers can
> be of great help.
... but we already have boost.coroutine for that ...
> Second, when decoding/parsing streaming data (data that is received
> piecemeal) that is separated by delimiters, you have to start decoding
> to see if you have received the delimiter. If not, then you have to
> receive more data and decode again. Rather than having to decode from
> the beginning every time, it is preferable to remember how far you got
> and continue from there. This can be done by integrating fibers with
> the decoder.
... also a perfect match for coroutines.
> In these use cases performance is of secondary importance.
What boost.fibers add is a scheduler and a compatibility layer for
boost/std thread, including locks, condvars and futures. You do not really
need these if you just need to thread your callbacks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk