[RFC] True Async RFC 1.7

Hello everyone!

RFC https://wiki.php.net/rfc/true_async

Here is the seventh version of the RFC, revised and expanded.

Version 1.7 (December 2025)

• Fiber integration: added Fiber::getCoroutine() method,
  ownership model, deadlock resolution
• Added Coroutine methods: getId(), getResult(), getException(),
  getTrace()
• Refined Goals section: improved clarity and technical accuracy of
  core value propositions
• Function naming aligned with PHP coding standards:
  currentCoroutine() → current_coroutine(),
  gracefulShutdown() → shutdown(),
  getCoroutines() → get_coroutines()
• Method renaming: Coroutine::onFinally() → Coroutine::finally() (brevity)
• Interface renaming: FutureLike → Completable
• Exception renaming: CancellationError → Cancellation (clearer semantics)
• Moved Cancellation to the root namespace (\Cancellation) as
  a fundamental PHP mechanism
• Changed Cancellation inheritance from \Error to \Throwable,
  following Python’s CancelledError pattern
• Added backward compatibility notes for the new root namespace class
• Renamed DeadlockException to DeadlockCancellation

My Comments

Since the vote took place, I have tried to bring together specialists
in asynchronous programming to discuss the RFC, and I was surprised by
the lack of serious disagreements. You can read the discussion on
GitHub, where key opinions from representatives of different libraries
and components are expressed.

These discussions became the basis for refining the RFC.
Compatibility research involving WordPress, Laravel, and AMPHP helped
clarify future prospects and potential challenges.

As part of the research, Xdebug was also adapted, without which
debugging WordPress code in coroutines would have been inconvenient. A
special version of Async-Worker for FrankenPHP was also developed.

Memory models were not included in the RFC because none of them
provide significant benefits, do not make the code noticeably better,
and all of them have drawbacks. Instead, future versions are expected
to introduce a separate API and philosophy for multithreaded
coroutines.

I returned to the original idea of defining the Cancellation exception
directly in the PHP core. This was always the right decision, and it
should not have been abandoned.

The most important change in this RFC is support for fibers as an
extended form of coroutines. It turned out to be a great idea.

I finally came up with a good term to replace FutureLike, which had
been really annoying me.

Experiments

To understand which code breaks, a special version of TrueAsync was
created that made GLOBALS unique per coroutine. This made it possible
to run WordPress as a stateful application with only a few changes.

Two versions of the code were implemented. One where WordPress was
fully initialized in each coroutine for every request, and another
where WordPress cloned only a subset of its data structures. Similar
experiments were also conducted on Laravel.

No more than 1–2 hours were spent on code changes for WordPress and
Laravel. In other words, there were almost no changes.

Automatic analysis of the Laravel codebase showed that the number of
components combining I/O operations with shared in-memory state is
extremely small compared to the amount of code that can work without
changes. Some WordPress functions with static variables continued to
work as before because they did not contain any I/O operations.

Overall, it became clear that the vast majority of the code remains
functional in a concurrent environment and works without changes. This
means that transparent async can actually save developers time and
money.

Key Conclusions

• One-thread coroutines are a powerful pattern for web-oriented
  programming languages, providing a balanced trade-off between system
  complexity, code safety, and developer ergonomics.

• Coroutines running in other threads do not contradict the
  one-thread model. They require further development and can integrate
  organically, complementing each other’s functionality.

• Actors are likely to become the next key pattern for
  multithreaded programming. Their implementation is clear, feasible,
  efficient, and surprisingly safe.

• Memory isolation and transfer mechanisms between PHP threads
  will not conflict with the current RFC. Instead, they will complement
  it and coexist alongside it.

I think having two tools for async, concurrent coroutines and
inter-thread interaction, can complement each other very well, and
most importantly, they can be built gradually, step by step.

This is, of course, a brief summary of the events of the past month,
so if I missed anything, please feel free to ask.

Merry Christmas to everyone!