On Windows and Linux, tasks are executed on lightweight threads known as fibers. Fibers allow tasks running on threads to schedule amongst themselves co-operatively, rather than relying on the operating system thread scheduler. The result is that a context switch between fibers is much less expensive than a thread context switch as there is no interaction with the operating system kernel or scheduler. In multi-threaded applications that otherwise do frequent thread context switching, the use of fibers can dramatically improve performance and scalability.

Because fibers do not rely on the operating system scheduler, a fiber must explicitly yield control to another fiber when it is waiting for some other activity to complete. For example, if a task that is executing on a fiber needs to block while waiting for an I/O operation to complete, it will relinquish control to another fiber. The thread hosting the original fiber is free to pick up another fiber immediately and begin its execution without a kernel context switch. If a fiber blocks and does not yield control, it blocks the thread that is hosting it and prevents other fibers from running on that thread. If more than one thread is hosting fibers, only the thread that is hosting the waiting fiber is blocked: other threads are still free to run fibers.

On platforms that support fibers, there are at least as many fibers created as required by the maximum concurrency setting of the server, as specified by the -gn option. The server may create more than this value so there is always a fiber available to service internal server tasks. See -gn server option.