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.

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.

// 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!

@rebecca20: Ajax calls should not be used for deferring/scheduling tasks, except for tasks that must wait for a server’s response. In your case, what you’re doing would be much better accomplished using successive calls to setTimeout — either way, Javascript is single-threaded and will execute the “threads” one by one.
.
Unless you have a good reason for delaying tasks (like running a large task in pieces so as to not block user interaction), you’re better off just running all your code sequentially. Javascript is not multi-threaded, but it does provide great performance for single-threaded routines that utilize setTimeout and callbacks to enable user interaction during long-running tasks or during calls to the server.
.
In the case of the above post, fibers are being utilized on server-side Javascript to boost performance when dealing with concurrent IO-handling tasks (“fibers”), probably in the context of Node.js or a similar setup.