The thread switching code assumed that we will always switch out of a
thread due to being blocked on an unavailable future. This allows
the core to store the blocked thread's context in the synthetic
continuation chained to that future (which switched back to that thread).
That assumption failed in one place: when we create a thread from within a
thread. In that case we switch to the new thread immediately, but forget
all about the old thread. We never come back to the old thread, and anything
that depends on it hangs.
Fix by creating a linked list of active thread contexts. These are all
threads that have been "preempted" by the act of creating a new thread,
terminated by the main, unthreaded, reactor context. This gives us a place
to store those threads and we come back to them and continue where we left
off.
Reported by Pekka.
swapcontext() is expensive as it invokes system calls. Replace it with
setjmp()/longjmp(). We still use setcontext() initially, since that's
the most reasonable portable method of setting up a stack.
Context switch time (measured by thread_context_switch) is reduced to
120ns (from 450ns), with inefficiencies in the test itself and in future<>
dominating.
Add a thread class that can be used to launch a blockable thread of
execution. Within a thread, future<>::get() can be called on an
unavailable future, in which case it blocks until the future is made ready.
