Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Nat Goodspeed (nat_at_[hidden])
Date: 2014-01-15 18:21:54

On Wed, Jan 15, 2014 at 6:03 PM, Hartmut Kaiser
<hartmut.kaiser_at_[hidden]> wrote:

>> Running one thread with multiple fibers is
>> guaranteed to introduce no new race conditions.

> If that's the case, then why does Boost.Fiber provide synchronization
> primitives to synchronize between fibers and support for work stealing? Or
> why is it implemented using atimics all over the place? Your statement does
> not make sense to me, sorry.

Because the library is more general than either of our individual use
cases. It addresses the scenario in which you need to coordinate a
fiber in one thread with a fiber (perhaps the one and only fiber)
running in another thread.

>> Emulating the std::thread API is intended to minimize coder confusion
>> -- not to provide a drop-in replacement.

> That's only one particular use case. Clearly we're talking about two
> different viewpoints where mine focusses on a very broad application for
> this kind of library, while yours is trying to limit it to a small set of
> use cases. While I accept the validity of these use cases I think it's not
> worth having a full Boost library just for those.

Hmm! With respect, it sounds to me as though you're saying: my use
case is important, yours is not.

You're saying that for your use case, performance is critical, and
performance would be the only reason you would choose Boost.Fiber over
other libraries available to you. I can respect that.

I'm saying that for my use case, performance is not critical, and
there is nothing in the standard library or presently in Boost that
addresses my semantic requirements. That sounds like reason enough to
have a Boost library.