On Thu, Jan 16, 2014 at 4:19 PM, Bjorn Reese
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