Boost logo

Boost :

Subject: Re: [boost] [Fibers] Performance
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-01-19 17:46:13

On 18/01/2014 04:01, Quoth Nat Goodspeed:
> Clearly all of this can be done with coroutines, yes. (Fiber does
> build it on coroutines!) But it's a whole additional abstraction
> layer. Must every developer facing this kind of use case build that
> layer by hand?

I asked that because Oliver seems to me to be focusing many of his
replies in this thread and elsewhere to "it makes Asio syntax cleaner",
which I don't feel is a sufficient justification for this library to
exist by itself, because Coroutine already does that.

I'm not saying that the library doesn't have merit for other reasons,
just that it's not being expressed very well.

> Consider a producer fiber obtaining input from some async source,
> pumping items into a queue. That queue is consumed by several
> different consumer fibers, each interacting with an async sink. All of
> it is running on a single thread. That's just one example.

If you are running on a single thread, you do not require any locks at
all on the queue, and barely any kind of synchronisation to have
consumers go to sleep when idle and be woken up when new work arrives.

Although granted this library would theoretically make life easier than
the alternatives if the consumers also needed to sleep on things other
than the queue itself -- though again, if you're running in one thread
you don't need locks, so there's not much you need to sleep on.

It's only really when you go to M:N that something like this becomes
especially valuable.

(Don't get me wrong -- I'm eagerly waiting for something like this,
because I *do* have a M:N situation in some of my code. But that code
is currently using Windows fibers, so I'm also interested in a
performance comparison.)

Boost list run by bdawes at, gregod at, cpdaniel at, john at