Re: [boost] [Fibers] Performance

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.

-- gpd