Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking Coroutines into C

wiomoc.de

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Hacking Coroutines into C

#11

Post by duped »

Neywiny wrote: post #3

The intent here is nice. I historically hate state machines for sequential executioners. To me they make sense in FPGA/ASIC/circuits. In software, they just get so complicated. I've even seen state managers managing an abstracted state machine implementing a custom device to do what's ultimately very sequential work. It's my same argument that there should be no maximum number of lines to a function. Sometimes, you j…

> I comment the code blocks, maybe with steps/parts, but there's no point in making a function that's only called in one place.

I encourage junior developers that get into this habit (getting worse now, with LLMs) to convert the comment into a function name and add the block as a function, thinking pretty carefully about its function signature. If you have a `typedef struct state` that gets passed around, great.

The reason for splitting up this code is so that the person writing it doesn't fuck up, the input/output is expressed as types and validated before they push it. It's easy for me to review, because I can understand small chunks of code better than big chunks, and logically divides up the high level architecture from the actual implementation so I can avoid reviewing the latter if I find trouble with the former. It's also good as a workflow, where you can pair to write out the high level flow and then split off to work on implementation internally. And most importantly, it makes it possible to test the code.

I have had this discussion with many grumbly developers that think of the above as a "skill issue." I don't really want to work with those people, because their code sucks.

Re: Hacking Coroutines into C

#12

Post by adinisom »

My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine:

  typedef struct blinky_state {
    size_t pc;
    uint64_t timer;
    ... variables that need to live across YIELDs ...
  } blinky_state_t;
  
  blinky_state_t blinky_state;
  
  #define YIELD() s->pc = __LINE__; return; case __LINE__:;
  void blinky(void) {
    blinky_state_t *s = &blinky_state;
    uint64_t now = get_ticks();
    
    switch(s->pc) {
      while(true) {
        turn_on_LED();
        s->timer = now;
        while( now - s->timer timer = now;
        while( now - s->timer
Can, of course, abstract the delay code into it's own coroutine.

Your company is probably using hardware containing code I've written like this.

What's especially nice that I miss in other languages with async/await is ability to mix declarative and procedural code. Code you write before the switch(s->pc) statement gets run on every call to the function. Can put code you want to be declarative, like updating "now" in the code above, or if I have streaming code it's a great place to copy data.

Re: Hacking Coroutines into C

#13

Post by csmantle »

adinisom wrote: post #12

My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine: typedef struct blinky_state { size_t pc; uint64_t timer; ... variables that need to live across YIELDs ... } blinky_state_t; blinky_state_t blinky_state; #define YIELD() s->pc = __LINE__; return; case __LINE__:; void blinky(void) { blinky_state_t *s = &blinky_…

Yeah. Protothreads (with PT_TIMER extensions) is one of the classics libraries, and also was used in my own early embedded days. I was totally fascinated by its turning ergonomic function-like macros into state machines back then.

Re: Hacking Coroutines into C

#14

Post by Nursie »

Cooperative multithreading via setjmp and longjmp has been around in C since the 80s at least.

I’m not sure this is so much hacking as an accepted technique from the old-old days which has somewhat fallen out of favour, especially as C is falling a little outside of the mainstream these days.

Perhaps it’s almost becoming lost knowledge :)

Re: Hacking Coroutines into C

#15

Post by fjfaase »

adinisom wrote: post #12

My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine: typedef struct blinky_state { size_t pc; uint64_t timer; ... variables that need to live across YIELDs ... } blinky_state_t; blinky_state_t blinky_state; #define YIELD() s->pc = __LINE__; return; case __LINE__:; void blinky(void) { blinky_state_t *s = &blinky_…

I have used this approach, with an almost similar looking define for YIELD myself.

If there is just one instance of a co-routine, which is often the case for embedded software, one could also make use of static variables inside the function. This also makes the code slightly faster.

You need some logic, if for example two co-routines need to access a shared peripheral, such as I2C. Than you might also need to implement a queue. Last year, I worked a bit on a tiny cooperative polling OS, including a transpiler. I did not finish the project, because it was considered too advanced for the project I wanted to use it for. Instead old fashion state machines documented with flow-charts were required. Because everyone can read those, is the argument. I feel that the implementation of state machines is error prone, because it is basically implementing goto statements where the state is like the label. Nasty bugs are easily introduced if you forget a break statement at the right place is my experience.

Re: Hacking Coroutines into C

#16

Post by adinisom »

fjfaase wrote: post #15
adinisom wrote: post #12

My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine: typedef struct blinky_state { size_t pc; uint64_t timer; ... variables that need to live across YIELDs ... } blinky_state_t; blinky_state_t blinky_state; #define YIELD() s->pc = __LINE__; return; case __LINE__:; void blinky(void) { blinky_state_t *s = &blinky_…

I have used this approach, with an almost similar looking define for YIELD myself. If there is just one instance of a co-routine, which is often the case for embedded software, one could also make use of static variables inside the function. This also makes the code slightly faster. You need some logic, if for example two co-routines need to access a shared peripheral, such as I2C. Than you might also need to impleme…

Yes, 100%. State transitions are "goto" by another name. State machines have their place but tend to be write-only (hard to read and modify) so are ideally small and few. Worked at a place that drank Miro Samek's "Practical Statecharts in C/C++" kool-aid... caused lots of problems. So instead I use this pattern everywhere that I can linearize control flow. And if I need a state machine with this pattern I can just use goto.

Agreed re: making the state a static variable inside the function. Great for simple coroutines. I made it a pointer in the example for two reasons:

- Demonstrates access to the state variables with very little visual noise... "s->"

- For sub-coroutines that can be called from multiple places such as "delay" you make the state variable the first argument. The caller's state contains the sub-coroutine's state and the caller passes it to the sub-coroutine. The top level coroutine's state ends up becoming "the stack" allocated at compile-time.

Re: Hacking Coroutines into C

#17

Post by ajb »

Nursie wrote: post #14

Cooperative multithreading via setjmp and longjmp has been around in C since the 80s at least. I’m not sure this is so much hacking as an accepted technique from the old-old days which has somewhat fallen out of favour, especially as C is falling a little outside of the mainstream these days. Perhaps it’s almost becoming lost knowledge :)

This isn't using setjmp/longjmp

It's using Simon Tatham's method based on Duff's device (https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html)

Re: Hacking Coroutines into C

#18

Post by dkjaudyeqooe »

adinisom wrote: post #12

My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine: typedef struct blinky_state { size_t pc; uint64_t timer; ... variables that need to live across YIELDs ... } blinky_state_t; blinky_state_t blinky_state; #define YIELD() s->pc = __LINE__; return; case __LINE__:; void blinky(void) { blinky_state_t *s = &blinky_…

A cleaner, faster way to implement this sort of thing is to use the "labels as values" extension if using GCC or Clang []. It avoids the switch statement and associated comparisons. Particularly useful if you're yielding inside nested loops (which IMHO is one of the most useful applications of coroutines) or switch statements.

[] https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Re: Hacking Coroutines into C

#20

Post by Nursie »

ajb wrote: post #17
Nursie wrote: post #14

Cooperative multithreading via setjmp and longjmp has been around in C since the 80s at least. I’m not sure this is so much hacking as an accepted technique from the old-old days which has somewhat fallen out of favour, especially as C is falling a little outside of the mainstream these days. Perhaps it’s almost becoming lost knowledge :)

This isn't using setjmp/longjmp It's using Simon Tatham's method based on Duff's device ( https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html )

Sure, I guess I just wanted to point out that regardless of method, people have been building these sorts of facilities in C for a very long time.

It doesn’t lessen the achievement of course, but it amuses me an in “everything old is new again” kinda way.

Post reply on HN