Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2014-01-16 07:51:48

[sorry for joining the discussion so late]

On Thu, Jan 16, 2014 at 12:35 PM, Oliver Kowalke
<oliver.kowalke_at_[hidden]>wrote:

> 2014/1/16 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>
>
> > I still don't get it. There is no API stability question. The API is well
> > defined for over 2 years now in the C++11 Standard (and even longer in
> > Boost.Thread).
>
>
> I could have choosen a different API for fibers - but I think the
> developers are
> more familiar with std::thread/boost::thread API.
>
>
> > So performance is the main incentive for such a library (what
> > could there be else?).
>
>
> with fibers you can suspend your execution context while keep the thread
> running (might execute something else). this is not possible with threads
> if they are suspend (yield(), waiting  on mutex/condition_variable).
>
> this feature of fiber enables you to write (again asio eve nif you don't
> care this
> use case).
>
> for (;;) {
>    ...
>    boost::asio::async_read( socket_, buffer, yield[ec]);
>    ...
> }
>
> async_write() suspends the current execution context (not the thread
> itself) and
> resumes it if all data have been read. without fibers you can't write the
> code like
> above (for-loop for instance).
> in the thread itself you can have more than one fibers running such
> for-loops.
>
> with threads you would have to pass a callback to async_read() and you
> could not
> invoke it inside a for-loop.
>
>
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
of thousands of threads, but that's feasible on a modern os/hardware pair.
The point of using fibers (i.e. M:N threading) is almost purely
performance.

-- gpd