The most dangerous phrase in the language is "We've always done it this way."
— Grace Hopper

The TrueAsync RFC process

TrueAsync is advancing the ability to change the PHP core through the RFC process.

Lead RFC
New RFCDraft

Async Scheduler Hook API

Author: Edmond [HT]v0.1PHP 8.x

A mechanism for activating concurrent execution at the PHP core level. The core exposes dedicated hooks that let the scheduler implementation live in a separate extension, or even in PHP code.

Key principles
  • Strict opt-in: zero overhead until a scheduler is registered
  • Fiber-compatible: existing Fiber code keeps working, and fibers are adopted onto the schedule
  • Continuation: a symmetric A→B context switch built on top of Fiber machinery
  • A single registration point: SchedulerHook::register() activates concurrency engine-wide
  • Per-coroutine context isolation: separate userland and internal contexts
  • Ecosystem freedom: the core standardizes only activation and the scheduler interface, while spawn() / await() / channels stay up to the implementation
Read the RFC on GitHub
Motivation

Why PHP needs built-in asynchrony

PHP is one of the last major languages that still lacks built-in support for concurrent execution at the language level. Python has asyncio, JavaScript is built on an event loop, Go has goroutines, Kotlin has coroutines. PHP remains in the "one request, one process" paradigm, even though most real-world applications spend the majority of their time waiting for I/O.

The fragmentation problem

Today async in PHP lives in extensions: Swoole, AMPHP, ReactPHP, each its own ecosystem with incompatible APIs.

  • Each extension rewrites its own MySQL / PostgreSQL / Redis drivers
  • A Swoole library doesn't work with AMPHP, and vice versa
  • Can't make core functions (file_get_contents, curl_exec) non-blocking
  • A high barrier to entry: a whole separate ecosystem to learn

The solution: an engine hook

TrueAsync adds a standard seam for concurrency at the PHP engine level.

  • Transparency: sync code runs in coroutines unchanged
  • No colored functions: no async/await marking
  • A unified standard: one scheduler interface in the engine for every extension
  • Backward compatibility: existing code keeps working

A typical PHP application (Laravel, Symfony, WordPress) spends 70–90% of its time waiting for I/O. With coroutines that idle time is used efficiently:

Scenario
Without coroutines
With coroutines
3 DB queries at 20ms each
60ms
~22ms
HTTP + DB + file
sequential
parallel
10 API calls
10 × latency
~1 × latency
Practical scenarios
Web servers · FrankenPHP, RoadRunnerAPI Gateway · parallel aggregationBackground tasks · concurrent queuesReal-time · WebSockets, streaming
History

Earlier RFCs

These two RFCs described a full concurrency model built directly into the core. The new approach builds on their ideas but moves the user-facing API out of the core, keeping only the scheduler attachment point in the engine.

RFC #1Draft

PHP True Async

Author: Edmond [HT]v1.7PHP 8.6+

The RFC defining a concurrency model for PHP. Describes coroutines, functions spawn() / await() / suspend(), the Coroutine object, Awaitable and Completable interfaces, cooperative cancellation, Fiber integration, error handling and graceful shutdown.

Key principles
  • Minimal changes to existing code to enable concurrency
  • Coroutines maintain the illusion of sequential execution
  • Automatic coroutine switching on I/O operations
  • Cooperative cancellation, "cancellable by design"
  • Standard C API for extensions
Read RFC on wiki.php.net
RFC #2Draft

Scope & Structured Concurrency

Author: Edmond [HT]v1.0

An extension of the True Async RFC. Introduces the Scope class, binding coroutine lifetime to the lexical scope. Describes scope hierarchy, error propagation, "zombie" coroutine policy and critical sections via protect().

What it solves
  • Preventing coroutine leaks beyond the scope
  • Automatic resource cleanup on scope exit
  • Hierarchical cancellation: cancelling the parent cancels all children
  • Protecting critical sections from cancellation
  • Deadlock and self-await detection
Read RFC on wiki.php.net

How these RFCs relate

The first RFC defines low-level primitives: coroutines, base functions and C API for extensions. The second adds structured concurrency: mechanisms for managing groups of coroutines that make concurrent code safe and predictable.

RFC #1: True Async
RFC #2: Scope
Level
Primitives
Management
Provides
spawn(), await(), Coroutine
Scope, TaskGroup, protect()
Analogies
Go goroutines, Kotlin coroutines
Kotlin CoroutineScope, Python TaskGroup
Goal
Running concurrent code
Safe lifecycle management

Join the Discussion

RFCs are discussed on the internals@lists.php.net mailing list and on GitHub Discussions. Also join the conversation on Discord.