What are use cases for coroutines?

The concept of a coroutine sounds very interesting, but I don't know, if it makes sense in a real productive environment? What are use cases for coroutines, where the coroutine implementation is more elegant, simpler or more efficient than other methods?

One use case is a web server that has multiple simultaneous connections, with a requirement to schedule reading and writing in parallel with all of them.

This can be implemented using coroutines. Each connection is a coroutine that reads/writes some amount of data, then yields control to the scheduler. The scheduler passes to the next coroutine (which does the same thing), cycling through all the connections.

Use case: coroutines are often used in game programming to time-slice computations.

To maintain a consistent frame rate in a game, e.g., 60 fps, you have about 16.6ms to execute code in each frame. That includes physics simulation, input processing, drawing/painting.

Lets say your method is executed in every frame. If your method takes a long time and ends up spanning multiple frames, you are going to stagger the rest of the computation in the game loop which results in the user seeing "jank" (a sudden drop in frame rate).

Coroutines make it possible to time slice the computation so that it runs a little bit in each frame.

For that to happen, coroutines allow the method to "yield" the computation back to the "caller" (in this case the game loop) so that the next time the method is called it resumes from where it left off.

Unix pipes are a use case:

grep TODO *.c | wc -l

The pipeline above is a coroutine. The grep command generates a sequence of lines and writes them to a buffer. The wc command reads these lines from the buffer. If the buffer fills up, then grep "blocks" until the buffer empties. If the buffer is empty, then wc waits for more input in the buffer.

Coroutines are more often used in more constrained patterns, like the Python generators mentioned, or as pipelines.

For more details and examples, read the Wikipedia articles, particularly coroutines and iterators.

True coroutines require language support. They need to be implemented by the compiler and supported by the underlying framework.

One language-supported implementation of coroutines is the C# 2.0 yield return keyword, which allows you to write a method that returns multiple values for looping.

The yield return does have limitations, however. The implementation uses a helper class to capture state, and it only supports the specific case of a coroutine as a generator (iterator).

In a more general case, an advantage of coroutines is that they make certain state-based computations easier to express and easier to understand. For example, implementing a state machine as a set of coroutines can be more elegant than other implementations. But doing this requires language support that doesn't yet exist in C# or Java.

Coroutines are useful to implement producer/consumer patterns.

For example, Python introduced coroutines in a language feature called generators, which was intended to simplify the implementation of iterators.

They can also be useful to implement cooperative multitasking, where each task is a coroutine that yields to a scheduler/reactor.

Coroutines can be useful when a system performs two or more tasks that would be most naturally described as a series of long-running steps that involve a lot of waiting.

For example, consider a device which has an LCD-and-keypad user interface and a modem, and it needs to use the modem to periodically call and report its status independent of what the user at the keypad is doing. The nicest way to write the user interface may be to use functions like "input_numeric_value(&CONV_SPEED_FORMAT, &conveyor_speed);" which will return when a user has entered a value, and the nicest way to handle the communication may be use functions like "wait_for_carrier();" which will return when the unit has either connected or determined it's not going to.

Without coroutines, either the UI subsystem or the modem subsystem would have to be implemented using a state machine. Using coroutines makes it possible for both subsystems to be written in the most natural style. Note that it's important that neither subsystem ever goes very long without putting things into a "consistent" state and calling yield(), nor calls yield() without putting things into a "consistent" state first, but it's usually not hard to meet those constraints.

Note that while one could use full-blown multitasking, that requires widespread use of locks or other mutual-exclusion constructs almost anyplace that shared state is altered. Since the coroutine switcher won't ever switch things except at yield() calls, either routine can freely alter shared state so long as it ensures that everything in in order before the next yield, and is prepared for the other routine to alter state "during" the yield().

As a producer/consumer example, a batch reporting program be implemented with coroutines.

The key hint for that example is having nontrivial work to consume input data (e.g. parsing data or accumulating charges and payments on an account), and nontrivial work to produce the output. When you have these characteristics, then:

• It is easy to organize/understand the input-side code if you can write units of work at various places.
• It is likewise easy to organize/understand the output-side code if it can read the next unit of work in a nested control structure.

then coroutines and queues are both nice techniques to have at your disposal.