In computer science, a fiber is a particularly lightweight thread of execution.
Like threads, fibers share address space. However, fibers use co-operative multitasking while threads use pre-emptive multitasking. Threads often depend on the kernel's thread scheduler to preempt a busy thread and resume another thread; fibers yield themselves to run another fiber while executing. The article on threads contains more on the distinction between threads and fibers.
Fibers describe essentially the same concept as coroutines. The distinction, if there is any, is that coroutines are a language-level construct, a form of control flow, while fibers are a systems-level construct, viewed as threads that happen not to run concurrently. Priority is contentious; fibers may be viewed as an implementation of coroutines, or as a substrate on which to implement coroutines.
The above is taken from Wikipedia, which is discussing the computer science concepts behind fibers.
Why do we bring this up? The Asana team (who we featured when they came out with LunaScript) continue their quest to make an ergonomic, productive, and performant framework for the Web.
Today they are discussing their patch to v8cgi that adds in support for their own fiber implementation.
It all ends up with this:
Few languages support fibers natively (though support was recently added to Ruby). We write most of our server code in JavaScript and run it under Google’s v8 engine, the same JS runtime that Chrome uses. Fortunately the v8 codebase is excellently structured, so we were able to add fiber support in just a few days. Our changes take the form of a patch (currently pending review) to v8cgi, a library of server-oriented extensions to v8.
Here’s a sample of the API:
JAVASCRIPT:
// Make a new fiber. The fiber will run the provided function. var fiber = new Fiber('name', function() { // ... // Make another fiber runnable. some_other_fiber.becomeRunnable(); // Suspend the current one. Fiber.current.suspend(); // ... }); // Make the new fiber runnable. It won't start until the current fiber suspends // or joins. fiber.becomeRunnable(); // Wait for the fiber to finish. fiber.join();That’s almost the entire API. We don’t need any synchronization primitives because only one fiber runs at a time and control only changes when suspend() or join() is called.
There is a tension between writing clear, well-abstracted code and writing code that makes efficient use of the database. Adding fibers to v8 allowed us to resolve this tension. In taking a small amount of time to solve this problem “right” up front, we’ve made our entire engineering team more efficient for the long run.
Read the post to get the background, and to see the refactoring that is done to get to this place.
Asana seems to be really enjoying rethinking the world of Web frameworks. I can't wait to see their products!

