ratchetfreak
If you don't have compiler or language support for coroutines you end up needing to implement a state machine for each of them. You'll need to save all variables that are alive at each yield explicitly.

Stack support (yielding in a nested call) will require the entire call stack supporting the yield by being yielding themselves.

Debugging is kinda a pain because it's not always obvious which state each coroutine object is in. This is especially true when the coroutine is created with compiler support because that will tend to hide the resume point.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

int function(void) {
    static int i, state = 0;
    switch (state) {
        case 0: /* start of function */
        for (i = 0; i < 10; i++) {
            state = 1; /* so we will come back to "case 1" */
            return i;
            case 1:; /* resume control straight after the return */
        }
    }
}

dannas


After reading this reply I found Simon Sathams article Coroutines in C that uses the stack for keeping track of where to reenter a function. I can see how that pattern resembles what Per wrote for the breakpoint_callback.

1 2 3 4 5 6 7 8 9 10 11

int function(void) { static int i, state = 0; switch (state) { case 0: /* start of function */ for (i = 0; i < 10; i++) { state = 1; /* so we will come back to "case 1" */ return i; case 1:; /* resume control straight after the return */ } } }

dannas

I guess two components which consumes data in "lock-step", are never required to use callbacks. For instance a lexer and a parser can be written as the lexer calling into a parser callback; or it could be rewritten using coroutines (we just need one-way communication there so a generator would do, yielding tokens); or it could be rewritten using an iterator-style API where we have state context and a next method, like the next_token() function used in the bitwise lexers. So this applies to all those "data in one form" to "data in another form" problems.

For two components where there's back-and-forth passing of control-flow, we can use two state machines; or threads with message passing between them; or the modules can be rewritten to use coroutines. But, as you mentioned, coroutines comes with a "mental cost". The control flow might be easier to follow for simple cases, but maybe the overhead of keeping track of states will consume the benefits for larger programs? Are there other ways of structuring command loop programs, besides these I mention here?

ratchetfreak

That doesn't use the stack but static local variables, which are essentially globals, except not accessible outside the function they are declared in

ratchetfreak

Maybe the best example I've seen is zlib's API, there after you init you pass an input buffer and an output buffer, it does its processing consuming from input and putting to output and returns once it cannot continue anymore because one of them ran out. Then the caller has to give more input or more output space as appropriate and call the function again.

This allows it to be easily slotted into either a push or a pull stack. Depending on which end controls the data rate.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

struct unzip_t unzip = { ... };
  unzip_init(&unzip);
  struct unzip_packet_t packet;
  while (unzip_next(&unzip, &packet)) {
    if (packet.type == UNZIP_FILE) {
      packet.file.address = zip_file_memory + packet.file.offset;
    } else if (packet.type == UNZIP_TOC) {
      free(toc);
      packet.toc.address = toc = malloc(packet.toc.size);
    }
  }
return unzip.status != UNZIP_ERROR;