Introduction

The main reason behind the development of Boost.Coroutine has been to find a solution to the inversion control problem in event driven web servers. From there the library has evolved to a general coroutine library, whose usefulness goes beyond event driven applications.

Both developing the library and writing the documentation have been a great learning exercise. The authors feels that it has only scratched the possibilities of coroutine oriented design.

Here are presented some useful additions to the library that have not been added yet for lack of time, lack of a complete understanding of the problem or both.

Pipelining

The producer/consumer example briefly mention the possibility of pipelining coroutines. This could be a powerful way of composing coroutines (and function objects in general), and should be explored further. This is not necessarily confined to this library though.

Output iterators

The generator class template provides an input iterator interface behind coroutines. For symmetry an output iterator interface is conceivable.

Generator caching

With the current implementation, a compiler cannot optimize (for example by inlining the coroutine in the caller) across a context switch barrier. It might be useful thus to do more work between context switches. This can be accomplished by returning more than one value at a time.

Currently the user must apply this optimization by hand, and both the caller and the callee must be aware of it. Boost.Coroutine might provide a way to do this transparently.

Context caching

Creating a coroutine requires dynamically allocating both the coroutine implementation and the coroutine stack. This could be a performance hit if coroutines are created and destroyed frequently. Unfortunately a normal custom allocator cannot be used because on some systems it is not possible to create the internal coroutine implementation and stack on user provided memory. Thus a context and stack caching system should be devised.

Future allocator

A future internal implementation is heap allocated. Futures should be considered cheap object to create, so it makes sense to provide the ability to specify an allocator if allocation becomes a bottleneck. An allocator that uses memory from the coroutine stack would be useful, and may be even the default. This would match well the future usage that requires a future not to outlive the owning coroutine.