Show HN: Libconcurrent – Coroutines in C

GCD is purely callback-based. It works neatly with Apple's "blocks" (inline capturing functions) extension to C, which make dealing with callbacks slightly nicer, but it's still just a sequence of callbacks.

Fully fledged coroutines let you save and resume execution in place. The main advantage is readability of conditional/looping control flow, which tends to quickly devolve into a mess in callback style code.

It would be helpful if the README explained how this is different than the many other coroutine libraries.

You might also want to look at lthread. It has some interesting functions like lthread_compute_begin()/end() to run expensive computations inside a coroutine. the compute methods move the coroutine into an actual pthread and resume until compute_end() is called. It also has c++11 bindings called lthread-cpp which allows you to launch coroutines with variable arguments & types and comes with nice socket wrappers.

  void MyMethod(std::vector my_vec) {}
  std::vector v{1,2,3,4};
  Lthread t1{&MyMethod, v};
  t1.detach()

  void my_coroutine()
  {
     lthread_compute_begin();
       ret = fibonacci(55);
     lthread_compute_end();
  }

No, i suggest to check lthread.

I wrote a networking daemon (SMTP greylisting proxy; now unmaintained, but http://spey.sf.net ) using coroutines once.

Non-preemptive multitasking made reasoning about the problem way easier, because I had no concurrency to worry about, while still allowing inversion of control flow which meant that the SMTP state machines were small and simple. It worked really well.

...until I started getting bug reports from users about weird irreproducable crashes. After a very, very long time I eventually figured out that if spey was built on a system where sqlite had been compiled with pthread support, then it automatically linked in a thread-safe malloc, which tried to fetch the current thread ID, which on some versions of pthreads on some Linux architectures on some glibc versions with some kernel versions, was stored at the top of the stack. It used alignment tricks to find this.

So, every time something called malloc(), the libc was doing the equivalent of:

    threadid = *(int*) (alignup(sp, 16MB) - sizeof(int))

Except my stacks weren't allocated through pthreads, so threadid ended up being garbage. Hilarity ensued.

I eventually rebuild the coroutine library to be a wrapper around pthreads with a big lock to ensure that only one would run at a time. Which was kind of evil, but much more reliable. (Previously I was using my own coroutine implementation based on getcontext/setcontext.)

So, uh. I can't remember if I had a point any more; but the pain remains.