Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129219
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com> <697c56c5-78bf-407a-a884-74ee150e992c@bastelstu.be>
In-Reply-To: <697c56c5-78bf-407a-a884-74ee150e992c@bastelstu.be>
Date: Thu, 13 Nov 2025 15:08:29 +0200
Message-ID: <CAMW7n8DQ=-n5TCMuNZRVSopmu2-AHor_TjNo5uF=w3jLaOtEkg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: php internals <internals@lists.php.net>, Jakub Zelenka <bukka@php.net>, 
	Larry Garfield <larry@garfieldtech.com>
Content-Type: text/plain; charset="UTF-8"
From: edmond.ht@gmail.com (Edmond Dantes)

Hello.

Mini Faq: https://github.com/true-async/php-true-async-rfc/blob/main/faq.md
Text here:

## Executive Summary: What This RFC Proposes

This RFC proposes adding **built-in concurrency support** to PHP
through two core components:

### 1. Coroutines via `spawn()`

Launch any PHP function as a lightweight coroutine that can be
suspended and resumed:
```php
use function Async\spawn;
use function Async\await;

$coroutine = spawn(file_get_contents(...), 'https://php.net');
$result = await($coroutine);
```

### 2. Non-blocking I/O Functions
**50+ existing PHP functions** automatically become non-blocking when
used inside coroutines:
- **Database**: PDO MySQL, MySQLi operations
- **Network**: CURL, sockets, streams, DNS lookups
- **Files**: `file_get_contents()`, `fread()`, `fwrite()`
- **Process**: `exec()`, `shell_exec()`, `proc_open()`
- **Timers**: `sleep()`, `usleep()`

**Key principle:** From the developer's perspective, these functions
work identically to their synchronous versions.
The difference is that they suspend only the current coroutine instead
of blocking the entire PHP process.

See full list: https://github.com/true-async/php-async#adapted-php-functions

### What This RFC Does NOT Propose
- **No changes to existing synchronous behavior** - code without
coroutines works exactly as before
- **No new syntax keywords** - uses function calls (`spawn()`,
`await()`, `suspend()`)
- **No changes to Fiber API** - Fibers and True Async are mutually
exclusive by design
- **No structured concurrency primitives** - covered in separate
[Scope RFC](https://wiki.php.net/rfc/true_async_scope)

## General Questions

### Q: What is the main goal of this RFC?

**A:** The RFC aims to provide a standardized way to write concurrent
code in PHP without requiring developers
to rewrite existing synchronous code. The key value proposition is
that existing code works **exactly the same**
inside a coroutine without modifications, unlike explicit async/await models.

### Q: How is this different from Fibers?

**A:** Fibers and True Async serve fundamentally different purposes
and cannot coexist:

**Fibers:**
- Low-level symmetric execution contexts
- Programmer explicitly controls switching (`$fiber->resume()`,
`Fiber::suspend()`)
- Direct access to execution stack management
- Suitable for building custom scheduling solutions

**True Async:**
- High-level asymmetric coroutines
- Automatic switching managed by the scheduler
- Transparent to the developer
- Designed for business logic, not infrastructure

**Why they can't work together:**

1. **Resource conflicts**: Both manage the same low-level resources
(execution context, CPU stack) in incompatible ways
2. **Architectural incompatibility**: Mixing symmetric (Fibers) and
asymmetric (coroutines) models creates unpredictable behavior
3. **Abstraction level**: Fibers expose low-level primitives in a
high-level language, violating the "Strict Layering" principle

**Why not map Fiber::suspend() to Async\suspend()?**

This would create a leaky abstraction:
- Fibers require explicit scheduling decisions (who to resume? when?)
- True Async scheduler makes these decisions automatically
- Mixing both models would break scheduler guarantees and lead to race
conditions
- The execution models are fundamentally incompatible (symmetric vs asymmetric)

If you need Fibers' explicit control, use Fibers.
If you want automatic concurrency for I/O-bound applications, use True Async.
Attempting to unify them would result in a solution that's neither
simple nor safe.

### Q: Isn't this just Fibers 2.0?

**A:** No. While both deal with execution contexts:
- Fibers require explicit switching and manual control
- True Async provides automatic scheduling and high-level primitives
- They solve different problems at different abstraction levels
- They are mutually exclusive by design

### Q: Can I use this with FPM?

**A:** Yes! True Async works in all execution modes including FPM.
The reactor activates within the context of
`php_request_startup/php_request_shutdown()`,
requiring no SAPI modifications.

### Q: What about `exit` and `die`?

**A:** They always trigger **Graceful Shutdown** mode:
- All coroutines in globalScope are cancelled
- Application continues execution without restrictions to shut down naturally
- This allows proper cleanup operations

### Q: Do I need to rewrite my existing code?

**A:** No. The main value of this implementation is that existing
synchronous code works inside coroutines without modification.
You can gradually adopt async features where beneficial.

### Q: How does this RFC affect I/O functions?

**A:** From the coroutine's perspective, I/O functions **do not change
their behavior**
they work exactly as they always have.
However, functions that previously blocked the entire PHP process now
only suspend the current coroutine,
allowing other coroutines to continue executing.

----
Best regards, Ed