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