PHP 8.6 Update: True Async gescheitert, PFA bestätigt

Im März 2026 habe ich in diesem Blog beschrieben, warum True Async und Partial Function Application die wichtigsten PHP-8.6-Kandidaten sind. Drei Monate später sieht die Lage anders aus: True Async hat die nötige Zweidrittel-Mehrheit im RFC-Voting nicht erreicht. PFA dagegen ist mit einer einstimmigen Abstimmung bestätigt. Und ein dritter RFC, der kaum Aufmerksamkeit bekam, wurde still implementiert und verändert die Async-Infrastruktur in PHP grundlegend.

Wer meinen März-Artikel zu PHP 8.6 gelesen hat, findet hier das Update. Ich habe den ursprünglichen Artikel nicht nachträglich geändert, weil er eine historische Momentaufnahme darstellt und die Suchtreffer erhalten bleiben sollen. Dieser Artikel ersetzt ihn inhaltlich. Am Ende des März-Artikels verweist ein Aktualisierungshinweis auf diesen Text.

PHP 8.6 Alpha 1 startet am 2. Juli 2026. GA ist für den 19. November 2026 geplant. Die Roadmap ist klar, die Feature-Liste auch. Was sich geändert hat, ist welche dieser Features überhaupt in der Liste stehen.

PHP 8.6 Status-Tabelle: Was kommt, was nicht

Warum ist True Async gescheitert?

Der True Async RFC scheiterte am 16. Februar 2026 daran, dass die nötige Zweidrittel-Mehrheit nicht erreicht wurde. Der RFC ist auf wiki.php.net/rfc/true_async als nicht angenommen dokumentiert.

Drei Argumente dominierten die Gegner-Seite:

Komplexität im Engine-Core: Spawn und await erfordern tiefgreifende Änderungen in der Zend-Engine-Architektur. Die Befürworter argumentierten, Fibers hätten das vorbereitet. Die Gegner sahen das anders: Fibers sind kooperativ und explizit, True Async würde implizite Unterbrechungspunkte in regulärem PHP-Code einführen.

Memory-Model-Fragen: PHP hat ein Execution-Modell, das auf Share-Nothing basiert. Jeder Request ist isoliert. True Async erzeugt parallele Ausführungspfade innerhalb desselben Prozesses. Was passiert mit Globals? Mit statischen Klassen-Properties? Mit Thread-Local-Storage? Die RFC-Autoren hatten Antworten, aber die Abstimmenden sahen das Risiko für unbekannte Edge-Cases als zu hoch.

Kulturelle Zurückhaltung: PHP ist in seiner Identität eine synchrone Sprache. Viele Kern-Entwickler sehen AMPHP, ReactPHP und Revolt als den richtigen Weg für Async-PHP, nicht eine Sprach-Level-Änderung. Ein Kommentar auf PHP Internals brachte es auf den Punkt: "We already have Fibers. Let the ecosystem build on top."

Was ist die Polling API und warum ist sie der stille Gewinner?

Der Polling API RFC (Autor: Jakub Zelenka) hat den Status Implemented. Er läuft unter dem Radar, ist aber architektonisch bedeutsamer als True Async es gewesen wäre, weil er das unterste Fundament legt, auf dem alle PHP-Async-Lösungen aufbauen.

Das Problem, das er löst: PHP hat bisher nur stream_select() für I/O-Multiplexing, basierend auf dem alten select()-Systemaufruf. Maximales File-Descriptor-Limit: 1.024. O(n) Komplexität. Kein Zugang zu epoll (Linux), kqueue (BSD/macOS) oder anderen modernen Polling-Mechanismen.

Das Ergebnis: AMPHP, ReactPHP und Revolt pflegen jeweils eigene Backend-Implementierungen (StreamSelect, ExtUv, ExtEvent, ExtEv), um auf modernen Polling-APIs aufzusetzen. Unterschiedliche Libraries, unterschiedliche Backends, kein einheitlicher Pfad.

// Polling API: neues Io\Poll Namespace in PHP 8.6
use Io\Poll\Context;
use Io\Poll\StreamPollHandle;
use Io\Poll\Event;

$context = new Context(); // wählt automatisch bestes Backend:
// epoll (Linux), kqueue (BSD/macOS), WSAPoll (Windows)

$handle = new StreamPollHandle($socket);
$watcher = $context->add($handle, [Event::Read, Event::Write]);

// Blockiert bis Event oder Timeout
$events = $context->wait(seconds: 0, microseconds: 500_000);

// Libraries wie AMPHP, ReactPHP, Revolt können das nutzen
// als einziges Backend statt 4 verschiedene zu pflegen

Der RFC ist klar in seiner Priorisierung: Die primäre Motivation ist ein internes API für PHP-Core und Extensions. Signal-Handling in FrankenPHP's ZTS-Mode, FPM-Worker-Event-Handling, plattformübergreifende Timer. Der Userspace-Teil (Io\Poll) ist der sekundäre Benefit.

Für Agenturen, die Symfony Messenger mit AMPHP oder Revolt betreiben: Die Polling API vereinheitlicht den Event-Loop-Unterbau, ohne dass Ihr Code sich ändert. Die Libraries werden ihre Backends auf Io\Poll migrieren.

Wie ich im Symfony 8.1-Artikel beschrieben habe, gehen HTTP-Less Applications und Fiber-basierte Worker in die gleiche Richtung. Die Polling API ist die Infrastruktur, die das langfristig trägt.

PFA: Was die 33:0-Abstimmung jetzt konkret bedeutet

Partial Function Application (PFA) ist mit 33 Ja-Stimmen, 0 Gegenstimmen bestätigt und implementiert. Das ist die einstimmigste Abstimmung in der PHP-8.6-Entwicklungsphase. Für PHP-Internals-Verhältnisse ist das ein klares Signal: Die Community war lange uneinig über den richtigen Ansatz, der endgültige Vorschlag überzeugte alle.

// PFA: Partial Function Application (PHP 8.6, Alpha 1 ab 02.07.2026)
function multiply(int $a, int $b): int
{
return $a * $b;
}

// Partial Application: erstes Argument fixieren
$double = multiply(2, ...); // Platzhalter = ...
$triple = multiply(3, ...);

echo $double(5); // 10
echo $triple(5); // 15

// Nützlich in Array-Funktionen:
$prices = [10.00, 25.50, 8.99];
$withTax = array_map(multiply(1.19, ...), $prices);
// [11.90, 30.345, 10.6981]

Was viele unterschätzen: PFA ist nicht nur Syntax-Zucker. Es verändert, wie Callback-basierter Code strukturiert wird. Statt Closures für einfache Parametrisierungen zu schreiben (fn($x) => multiply(2, $x)), gibt es einen direkten Sprachkonstrukt. Das reduziert Closure-Overhead und macht Composer-Pipelines lesbarer.

Für Symfony-Projekte besonders relevant: Console-Commands, die Transformationspipelines über Arrays aufbauen, Middleware-Stacks, Twig-Filter-Callbacks. Überall dort, wo heute fn($x) => someFunction($fixedArg, $x) steht, kommt PFA.

Was bedeutet das für Ihre Architektur-Entscheidungen?

Im März-Artikel hatte ich drei Empfehlungen gegeben, die sich durch das True-Async-Scheitern teilweise verschieben:

Stateless Services bleiben sinnvoll (für PFA). Pure Functions, keine Seiteneffekte, testbare Transformationen. Das zahlt auf PFA ein und war unabhängig von True Async richtig.

Das große Async-Refactoring kann entspannen. Wer geplant hatte, seinen Code für True Async umzustrukturieren (explizite async/await Markierungen), braucht das nicht. Fibers + Revolt + Symfony Messenger sind der stabile Weg. Die Polling API verbessert deren Performance ohne Code-Änderungen.

Wer jetzt AMPHP, ReactPHP oder Revolt einsetzt, profitiert ab PHP 8.6 von der Polling API als einheitlichem Unterbau. Kein manueller Extension-Wechsel, keine Konfiguration. Die Libraries werden das intern migrieren.

Zusammenfassung

True Async ist gescheitert. Die nötige Zweidrittel-Mehrheit wurde nicht erreicht. Spawn und await kommen nicht in PHP 8.6. Die Argumente: Engine-Komplexität, Memory-Model-Risiken, Fibers als ausreichende Antwort.

Polling API ist implementiert. Io\Poll Namespace mit Context, Watcher, StreamPollHandle. Backends: epoll, kqueue, WSAPoll. AMPHP, ReactPHP und Revolt können auf ein einziges Backend migrieren. FrankenPHP ZTS profitiert sofort.

PFA kommt mit 33:0. Alpha 1 am 2. Juli 2026, GA am 19. November 2026. Platzhalter-Syntax ..., kein Closure-Overhead, saubere Pipelines.

Die Architektur-Empfehlung: Stateless Services und Pure Functions bleiben richtig. Symfony Messenger + Revolt ist der stabile Async-Weg. Kein Async-Refactoring aus Angst vor True Async nötig.