I wrote a networking daemon (SMTP greylisting proxy; now unmaintained, but <plug> <a href="http://spey.sf.net" rel="nofollow">http://spey.sf.net</a> </plug>) using coroutines once.<p>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.<p>...until I started getting bug reports from users about weird irreproducable crashes. After a very, <i>very</i> 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.<p>So, every time something called malloc(), the libc was doing the equivalent of:<p><pre><code> threadid = *(int*) (alignup(sp, 16MB) - sizeof(int))
</code></pre>
Except my stacks weren't allocated through pthreads, so threadid ended up being garbage. Hilarity ensued.<p>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.)<p>So, uh. I can't remember if I had a point any more; but the pain remains.
The links to other projects with similar goals at the bottom of the Readme is brilliant. It helps developers solve their problems irrespective of whether this particular solution works...and solving problems not stars and forks is the measure of utility for a library.
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.<p><pre><code> void MyMethod(std::vector<int> my_vec) {}
std::vector<int> v{1,2,3,4};
Lthread t1{&MyMethod, v};
t1.detach()
void my_coroutine()
{
lthread_compute_begin();
ret = fibonacci(55);
lthread_compute_end();
}</code></pre>
Cool!<p>A co-TA and I ported the concurrency library in JOS, MIT's teaching operating system, to regular UNIX:<p><a href="https://github.com/geofft/vireo" rel="nofollow">https://github.com/geofft/vireo</a><p>It uses the standard-ish library functions setcontext and getcontext to avoid an assembly dependency. ("POSIX.1-2008 removes the specification of getcontext(), citing portability issues, and recommending that applications be rewritten to use POSIX threads instead.")
How does this compare to Apple's GCD [1]?<p>1 - <a href="https://en.wikipedia.org/wiki/Grand_Central_Dispatch" rel="nofollow">https://en.wikipedia.org/wiki/Grand_Central_Dispatch</a>