Re: [boost] [Fibers] Performance

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.)