Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129247
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <CAEKnhAGJhR-EK_tjOBC78HUyiL0m_vJ-_toJgLdT8LLx+hREig@mail.gmail.com>
 <CAMW7n8CC8sq8hs2gLsDcr-78GehzHk+cAMR=pRsL9gim3=ovbw@mail.gmail.com>
 <CAEKnhAEoBdU-LpoXAGpAT0VNiphLWEfWqsJ6L-1NoQ0m0eYzTw@mail.gmail.com>
 <CAMW7n8AAf0Cn04c_xNmw6oV8fka3bh1Qgs1rKM4N+4kDYHUmGA@mail.gmail.com> <CAEKnhAHCG5KP3y2Y9njHRZPSscU=_+mAm-Krvxc33K-kptsxEA@mail.gmail.com>
In-Reply-To: <CAEKnhAHCG5KP3y2Y9njHRZPSscU=_+mAm-Krvxc33K-kptsxEA@mail.gmail.com>
Date: Sun, 16 Nov 2025 00:02:41 +0200
Message-ID: <CAMW7n8BTV07f3YFF8yEy0N_ZCV9c9hZ3f=GUEd0HegqcLdXzmQ@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: Jakub Zelenka <bukka@php.net>
Cc: php internals <internals@lists.php.net>, Larry Garfield <larry@garfieldtech.com>
Content-Type: text/plain; charset="UTF-8"
From: edmond.ht@gmail.com (Edmond Dantes)

Hello

> It's 1.6k lines so it might help a little bit
Yeah :)

> Why do you need reactor for this specific part of proposal? The thing is that there shouldn't be any IO so you reduce scheduler code as well and make it simpler and more reviewable.

So you are suggesting removing all I/O from the RFC. On the one hand,
that sounds appealing. It immediately eliminates a bunch of tests. But
there is a trap we could all fall into.
By separating the reactor and the scheduler, as well as the rules of
how they work together, we might accidentally introduce an error into
the document simply because the documents would be split.
(interface drift)

The fact that the I/O rules and coroutine rules are part of a single
document developed together is actually an advantage, just as the
existence of separate RFCs for await and Scope is. And this does not
prevent splitting the implementation code into many small parts.

On the other hand, STREAM has corner cases, especially in error
situations, that would be appropriate to discuss and formalize in a
separate RFC. Ideally, this should probably be done right before
accepting the STREAM PR. However, such a description does not carry
significant risks.

This requires some thought.