Why PHP Fibers Aren’t Asynchronous Magic – Understanding Their True Power

Fibers Misunderstood

PHP Fibers are not asynchronous PHP, they are not parallel processing, threads, or a way to run multiple things at once.

When PHP 8.1 introduced fiber support in November 2021, many developers wondered, “Great, another async thing?” The confusion is understandable because the most obvious use‑case for fibers is in async libraries such as ReactPHP and AmPHP.

What Is Cooperative Multitasking?

Think of a standard PHP script as a train on a single track that runs from point A to point B without stopping. Fibers let the train stop midway, let passengers off (or go to the restroom), let another train use the track for a while, and then resume exactly where it left off, preserving all variables and memory state.

In programming terms:

Pre‑emptive multitasking – the OS forcibly interrupts your code (threads, processes).

Cooperative multitasking – your code decides when to yield control (coroutines, fibers).

Fibers implement cooperative multitasking in PHP. They let you:

Start executing a block of code.

Pause it at any point (suspend).

Do other work.

Resume precisely where you left off.

Repeat as needed.

Fiber Anatomy – A Simple Example

<?php
$fiber = new Fiber(function(): string {
    echo "1. Fiber started
";
    $value = Fiber::suspend('pause-1');
    echo "3. Fiber resumed with: $value
";
    $value2 = Fiber::suspend('pause-2');
    echo "5. Fiber resumed again with: $value2
";
    return 'final-result';
});

echo "0. Before starting fiber
";
$suspended1 = $fiber->start();
echo "2. Fiber suspended with: $suspended1
";
$suspended2 = $fiber->resume('data-1');
echo "4. Fiber suspended again with: $suspended2
";
$result = $fiber->resume('data-2');
echo "6. Fiber returned: $result
";
?>

Output:

0. Before starting fiber
1. Fiber started
2. Fiber suspended with: pause-1
3. Fiber resumed with: data-1
4. Fiber suspended again with: pause-2
5. Fiber resumed again with: data-2
6. Fiber returned: final-result

The key insight is that the code inside a fiber does not need to know it is running inside a fiber.

Fibers in Async Libraries

Before fibers, asynchronous PHP code relied on deeply nested promises:

function fetchUserData(int $userId): PromiseInterface {
    return $this->httpClient->getAsync("/users/$userId")
        ->then(fn($response) => json_decode($response->getBody()))
        ->then(fn($userData) => $this->cache->setAsync("user:$userId", $userData))
        ->then(fn() => "User $userId cached");
}

With fibers, the same logic becomes much clearer:

function fetchUserData(int $userId): string {
    $response = await($this->httpClient->getAsync("/users/$userId"));
    $userData = json_decode($response->getBody());
    await($this->cache->setAsync("user:$userId", $userData));
    return "User $userId cached";
}

The await() helper suspends the current fiber, registers the promise with the event loop, and resumes when the promise resolves, making asynchronous code look synchronous.

Fully Transparent Async

Libraries like AmPHP can hide await() entirely, exposing methods that appear synchronous while the library uses fibers internally:

class HttpClient {
    public function get(string $url): Response {
        $promise = $this->performAsyncRequest('GET', $url);
        $response = Fiber::suspend(['type' => 'await', 'promise' => $promise]);
        if ($response instanceof \Throwable) {
            throw $response;
        }
        return $response;
    }
}

From the caller’s perspective, get() simply returns a response; the asynchronous nature is completely hidden.

Real‑World Problem: MCP SDK Client Communication

The author uses a Model Context Protocol (MCP) PHP implementation to illustrate a design challenge. Three fibers – ProcessSaladTask, WashVegetablesTask, and PrepareBowlTask – are started, each suspending for a timed delay. A central TaskManager switches between them when their delays expire, achieving parallel‑like execution without threads.

Example task definitions (simplified):

class BoilWaterTask extends Task {
    protected function execute(): mixed {
        echo "   Boiling water...
";
        wait(seconds: 2.0);
        return "water_ready";
    }
}

class PrepareSauceTask extends Task {
    protected function execute(): mixed {
        echo "   Preparing sauce...
";
        wait(seconds: 1.5);
        return "sauce_ready";
    }
}

The ProcessPastaTask starts both tasks in parallel, then waits for the water, cooks pasta, and finally waits for the sauce, demonstrating a mixed parallel‑then‑sequential workflow.

$manager = new TaskManager();
$manager->add(new ProcessPizzaTask());
$manager->add(new ProcessSaladTask());
$manager->add(new ProcessPastaTask());
$manager->add(new CleanupTask());
$manager->addInterval(2.0, fn() => echo "[Monitor] Kitchen status check
");
$manager->run();

The interleaved output shows true concurrency: tasks progress while others wait, reducing total execution time from ~18 s (sequential) to ~8 s (cooperative).

When to Use Fibers

You need to pause and later resume execution (core use‑case).

You want to hide complexity behind a clean API (e.g., library design).

You need cooperative multitasking without threads or processes.

You are bridging synchronous and asynchronous code so async operations appear synchronous.

You require full execution‑context preservation beyond what generators offer.

You are building infrastructure code – libraries, frameworks, SDKs.

When Not to Use Fibers

Simple callbacks suffice – avoid unnecessary complexity.

You need true parallelism – fibers are cooperative, not parallel.

Your code is linear and has no need for interruption.

You don’t control the execution flow – fibers shine in libraries, not in top‑level application code.

Generators solve the problem cleanly – prefer them if they are sufficient.

Common Pitfalls & Considerations

Know Who Controls the Fiber – When a fiber suspends, control returns to the coordinator (e.g., $fiber->start() or $fiber->resume() caller). The coordinator decides when to resume.

Don’t Forget You Are Inside a Fiber – Code after a suspension runs later; think about state changes that may happen while paused.

Resource Lifetimes – Locks, DB transactions, file handles, etc., must remain valid across suspension points.

Exception Handling Across Suspensions – Exceptions thrown inside a fiber bubble to the coordinator via start() / resume(). Exceptions from the coordinator do not automatically propagate into the fiber.

Global State – Other fibers may modify globals while you are suspended; avoid relying on mutable global state.

Fiber Creation Overhead – Fibers are lightweight but not free; avoid creating millions of them.

Conclusion

Just as learning data structures means knowing when to apply them, mastering PHP fibers means recognizing problems that require pausing and resuming execution, clean API design, and cooperative multitasking. When you encounter such scenarios, ask yourself whether a fiber can solve the problem elegantly – the answer is often yes.

GitHub repository with the full kitchen‑scheduler example: https://github.com/CodeWithKyrian/php-fiber-kitchen-scheduler